Architecture and Design Checklist

From Guidance Share

(Difference between revisions)
Jump to: navigation, search

Revision as of 16:59, 29 March 2010


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