Software Architecture can be described as structure of system, where system represents the collection of components that accomplish a set of functions. This post explains the key design principles for software architecture.
The above picture shows you the common application architecture and different components in the system and how they work together.
- Separation of Concerns Break your application into distinct features.
- Prefer composition over inheritance When reusing the functionality use composition over inheritance because inheritance increases the dependency between parent and child classes.
- Don’t Repeat Yourself(DRY) Define only one component for providing specific functionality and should not be duplicated in any other component.
When designing a application, software architect is to minimize the complexity by separating the design into different areas. For example UI processing components should not include code that directly access a data source, instead it should use data access components to retrieve data.
Failure to design a good authentication strategy can leave your application vulnerable to spoofing attacks and session hijacking.
Consider the following guidelines when designing the authentication strategy
- Identify your trust boundaries
- If you have multiple systems with in the application consider using the single sign-on strategy.
- Store the hash of the passwords in the database.
- Enforce the use of strong passwords.
Consider the following guidelines when you are designing the authentication strategy
- Protect resources by applying authorization to callers based on their identity.
- Use resource-based authorization for system auditing.
Caching improves the performance and responsiveness of your application.
- You should use the cache for avoiding network round trips and avoid duplicate processing of data.
- Do not cache the volatile data.
- Do not cache the sensitive data unless you encrypt it.
It concerns the interaction between components across the layers. When crossing the physical boundaries, you should use message-based communication.
- Build the service interfaces for communication
- Consider using MSMQ to queue messages for later delivery.
Concurrency and Transactions
When designing for concurrency and transactions for accessing the database it is important to identify the concurrency data model that you want to use. The model can be optimistic or pessimistic.
- If you have business-critical operations, consider wrapping them in transactions.
- Use connection-based transactions when accessing a single-data source.
- Updates to shared data should be mutually exclusive, which is accomplished by applying locks.
- Avoid holding locks for longer period.
- Encrypt sensitive information in configuration store.
- Provide separate administrative interface for editing configuration information.
- Categorize the configuration items into logical sections.
Designing a Data Access Layer is important for application maintainability. The Data Access Layer should be responsible for managing connections and executing commands against data source.
- Avoid accessing database directly from other layers and should have the data access layer interaction for DB operations.
- Release the DB connections as early as possible.
Good Design of exception-management strategy is important for the reliability of your application.
- Do not catch the internal exceptions unless you can handle them.
- Design a appropriate exception propagation strategy.
- Design a strategy for unhandled exceptions.
- Design a appropriate logging and notification strategy.
Designing the layers allows you to separate the functionality into different areas of concern.
- Layers should represent the logical grouping of components.
- Components with in a layer should be cohesive means business layer components should provide options only related to application business logic.
|Share this post :|