Architecture and Design Checklist

From Guidance Share

Jump to: navigation, search


Checklist - Architecture and Design

Design Considerations

  • Areas of concern are separated.
  • Every component has a single responsibility.
  • Components do not rely on the internal details of other components.
  • Functionality is not duplicated within the application.
  • Components are grouped logically into layers.
  • Abstraction is used to design loose coupling between layers.


  • Trust boundaries have been identified, and users are authenticated across trust boundaries.
  • Single sign-on is used when there are multiple systems in the application.
  • Passwords are stored as a salted hash, not plain text.
  • Strong passwords or password phrases are enforced.
  • Passwords are not transmitted in plain text.


  • Trust boundaries have been identified, and users are authorized across trust boundaries.
  • Resources are protected with authorization on identity, group, claims or role.
  • Role-based authorization is used for business decisions.
  • Resource-based authorization is used for system auditing.
  • Claims-based authorization is used for federated authorization based on a mixture of information such as identity, role, permissions, rights, and other factors.


  • Volatile data is not cached.
  • Data is cached in ready to use format.
  • Unencrypted sensitive data is not cached.
  • Transactional resource manager or distributed caching is used, if your application is deployed in Web farm.
  • Your application does not depend on data still being in cache.


  • Interfaces support chunky communication to reduce calls.
  • Unmanaged code is used for communication across AppDomain boundaries.
  • Message-based communication is used when crossing process or physical boundaries.
  • Processing threads use asynchronous communication.
  • Message queuing is used for reliable messaging.


  • Dynamic layouts are not used, if they need to be used maintenance tradeoff are considered.
  • Abstraction is used between components to improve maintainability.
  • Template View pattern is used, to improve reuse and consistency of dynamic web pages.
  • Composite View pattern is used to compose views from modular atomic parts.

Concurrency and Transactions

  • Business-critical operations are wrapped in transactions.
  • Connection-based transactions are used in the case of a single data source.
  • Transaction Scope (System.Transaction) is used in the case of multiple data sources.
  • Compensating methods are used to revert the data store to its previous state when transactions are not used.
  • Locks are not held for long periods during long-running atomic transactions.

Configuration Management

  • Least-privileged process and service accounts are used.
  • All the configurable application information is identified.
  • Sensitive information in the configuration is encrypted.
  • Access to configuration information is restricted.
  • If there is a configuration UI, it is provided as a separate administrative UI.

Coupling and Cohesion

  • Application is partitioned into logical layers.
  • Layers use abstraction through interface components, common interface definitions, or shared abstraction to provide loose coupling between layers..
  • The components inside layers are designed for tight coupling, unless dynamic behavior requires loose coupling.
  • Each component only contains functionality specifically related to that component.
  • The tradeoffs of abstraction and loose coupling are well understood for your design. For instance, it adds overhead but it simplifies the build process and improves maintainability.

Data Access

  • Database schema is not coupled to your application model.
  • Connections are opened as late as possible and released quickly.
  • Data integrity is enforced in the database, not in the data access layer.
  • Business decisions are made in the business layer, not the data access layer.
  • Database is not directly accessed; database access is routed through the data access layer.
  • Resource gateways are used to access resources outside the application.

Exception Management

  • Exceptions are only caught where they can be handled.
  • Sensitive information is not included in exception messages or log files.
  • There is a design for exception propagation.
  • There is a strategy for handing unhandled exceptions.
  • There is a strategy for logging exception information.
  • Users are notified when there are critical errors and exceptions.


  • Layers represent a logical grouping of components. For example, use separate layers for user interface, business logic, and data access components.
  • Components within each layer are cohesive. For example, the business layer components should provide only operations related to application business logic.
  • When communication between layers crosses a physical tier, message-based operations are used.
  • When communication does not cross a physical boundary, object-based operations are used.
  • If testability is important, an Interface type has been defined for the interfaces in each layer.

Logging and Instrumentation

  • There is a centralize logging and instrumentation mechanism.
  • System events and critical business events are instrumented.
  • The design includes a strategy for passing audit and log information across tiers.
  • Log files are secured against unauthorized access.
  • Sensitive information is not stored in log files.

State Management

  • The only data persisted is what’s necessary to maintain state.
  • State is serialized if it needs to be persisted or shared across the network.
  • Basic types are used for session data to reduce the serialization cost.
  • Session state communication channel is protected.
  • SQL Server state store is used, if reliability is the primary concern.


  • Your design is based on a common application structure such as Client/Server or N-Tier.
  • Deployment environment security requirements are well understood. For example, many security policies require physical separation of presentation logic from business logic across different sub-nets.
  • Scalability and reliability requirements are well understood for your application.
  • Deployment scenarios are well understood for your application.

User Experience

  • The design includes a consistent navigation experience. For example, composite patterns for the look-and-feel, and controller patterns such as MVC, Supervising Controller, and Passive View, for UI processing.
  • Each page or section is focused on a specific task.
  • Similar UI components have consistent behavior across the application. For example, a grid used to display data should be displayed and used consistently throughout the application.
  • UI screens are not overloaded.


  • Trust boundaries are identified, and all the inputs are validated when they cross the trust boundary.
  • A centralized validation approach is used.
  • Validation strategy constrains, rejects, and sanitizes malicious input.
  • Input data is validated for length, format, and type.
  • Client-side validation is used for user experience and server-side validation is used for security.


  • Workflow management requirements are well understood.
  • There is a strategy for handling workflow exceptions.
  • Service interfaces are used to interact with external workflow providers.
  • Designers and metadata are used, where possible, to define workflow.
Personal tools