Architecture and Design Checklist
From Guidance Share
(Difference between revisions)
Revision as of 16:59, 29 March 2010 (edit) Webmaster (Talk | contribs) ← Previous diff |
Current revision (17:01, 29 March 2010) (edit) Webmaster (Talk | contribs) |
||
Line 7: | Line 7: | ||
===Design Considerations=== | ===Design Considerations=== | ||
- | + | * Areas of concern are separated. | |
- | • * 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. | |
- | • * Every component has a single responsibility. | + | * Components are grouped logically into layers. |
- | + | * Abstraction is used to design loose coupling between layers. | |
- | + | ||
- | • * 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. | + | |
Line 29: | Line 18: | ||
- | • * Trust boundaries have been identified, and users are authenticated across trust boundaries. | + | * 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. | |
- | • * Single sign-on is used when there are multiple systems in the application. | + | * Strong passwords or password phrases are enforced. |
- | + | * Passwords are not transmitted in plain text. | |
- | + | ||
- | • * Passwords are stored as a salted hash, not plain text. | + | |
- | + | ||
- | + | ||
- | • * Strong passwords or password phrases are enforced. | + | |
- | + | ||
- | + | ||
- | • * Passwords are not transmitted in plain text. | + | |
Line 47: | Line 28: | ||
- | • * Trust boundaries have been identified, and users are authorized across trust boundaries. | + | * 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. | |
- | • * Resources are protected with authorization on identity, group, claims or role. | + | * 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. | |
- | + | ||
- | • * 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. | + | |
Line 65: | Line 38: | ||
- | • * Volatile data is not cached. | + | * Volatile data is not cached. |
- | + | * Data is cached in ready to use format. | |
- | + | * Unencrypted sensitive data is not cached. | |
- | • * Data is cached in ready to use format. | + | * 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. | |
- | + | ||
- | • * 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. | + | |
Line 83: | Line 48: | ||
- | • * Interfaces support chunky communication to reduce calls. | + | * 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. | |
- | • * Unmanaged code is used for communication across AppDomain boundaries. | + | * Processing threads use asynchronous communication. |
- | + | * Message queuing is used for reliable messaging. | |
- | + | ||
- | • * Message-based communication is used when crossing process or physical boundaries. | + | |
- | + | ||
- | + | ||
- | • * Processing threads use asynchronous communication. | + | |
- | + | ||
- | + | ||
- | • * Message queuing is used for reliable messaging. | + | |
Line 101: | Line 58: | ||
- | • * Dynamic layouts are not used, if they need to be used maintenance tradeoff are considered. | + | * 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. | |
- | • * Abstraction is used between components to improve maintainability. | + | * Composite View pattern is used to compose views from modular atomic parts. |
- | + | ||
- | + | ||
- | • * 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. | + | |
Line 116: | Line 67: | ||
- | • * Business-critical operations are wrapped in 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. | |
- | • * Connection-based transactions are used in the case of a single data source. | + | * 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. | |
- | + | ||
- | • * 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. | + | |
Line 134: | Line 77: | ||
- | • * Least-privileged process and service accounts are used. | + | * Least-privileged process and service accounts are used. |
- | + | * All the configurable application information is identified. | |
- | + | * Sensitive information in the configuration is encrypted. | |
- | • * All the configurable application information is identified. | + | * Access to configuration information is restricted. |
- | + | * If there is a configuration UI, it is provided as a separate administrative UI. | |
- | + | ||
- | • * 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. | + | |
Line 152: | Line 87: | ||
- | • * Application is partitioned into logical layers. | + | * 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. | |
- | • * Layers use abstraction through interface components, common interface definitions, or shared abstraction to provide loose coupling between layers.. | + | * 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. | |
- | + | ||
- | • * 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. | + | |
Line 170: | Line 97: | ||
- | • * Database schema is not coupled to your application model. | + | * 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. | |
- | • * Connections are opened as late as possible and released quickly. | + | * 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. | |
- | • * 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. | + | |
Line 191: | Line 108: | ||
- | • * Exceptions are only caught where they can be handled. | + | * 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. | |
- | • * Sensitive information is not included in exception messages or log files. | + | * 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. | |
- | • * 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. | + | |
Line 212: | Line 119: | ||
- | • * Layers represent a logical grouping of components. For example, use separate layers for user interface, business logic, and data access components. | + | * 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. | |
- | • * Components within each layer are cohesive. For example, the business layer components should provide only operations related to application business logic. | + | * 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. | |
- | + | ||
- | • * 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. | + | |
Line 230: | Line 129: | ||
- | • * There is a centralize logging and instrumentation mechanism. | + | * 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. | |
- | • * System events and critical business events are instrumented. | + | * Log files are secured against unauthorized access. |
- | + | * Sensitive information is not stored in log files. | |
- | + | ||
- | • * 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. | + | |
Line 248: | Line 139: | ||
- | • * The only data persisted is what’s necessary to maintain state. | + | * 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. | |
- | • * State is serialized if it needs to be persisted or shared across the network. | + | * Session state communication channel is protected. |
- | + | * SQL Server state store is used, if reliability is the primary concern. | |
- | + | ||
- | • * 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. | + | |
Line 266: | Line 149: | ||
- | • * Your design is based on a common application structure such as Client/Server or N-Tier. | + | * 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 environment security requirements are well understood. For example, many security policies require physical separation of presentation logic from business logic across different sub-nets. | + | * Deployment scenarios are well understood for your application. |
- | + | ||
- | + | ||
- | • * Scalability and reliability requirements are well understood for your application. | + | |
- | + | ||
- | + | ||
- | • * Deployment scenarios are well understood for your application. | + | |
Line 281: | Line 158: | ||
- | • * 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. | + | * 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. | |
- | • * Each page or section is focused on a specific task. | + | * UI screens are not overloaded. |
- | + | ||
- | + | ||
- | • * 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. | + | |
Line 296: | Line 167: | ||
- | • * Trust boundaries are identified, and all the inputs are validated when they cross the trust boundary. | + | * 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. | |
- | • * A centralized validation approach is used. | + | * 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. | |
- | + | ||
- | • * 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. | + | |
Line 314: | Line 177: | ||
- | • * Workflow management requirements are well understood. | + | * Workflow management requirements are well understood. |
- | + | * There is a strategy for handling workflow exceptions. | |
- | + | * Service interfaces are used to interact with external workflow providers. | |
- | • * There is a strategy for handling workflow exceptions. | + | * Designers and metadata are used, where possible, to define workflow. |
- | + | ||
- | + | ||
- | • * Service interfaces are used to interact with external workflow providers. | + | |
- | + | ||
- | + | ||
- | • * Designers and metadata are used, where possible, to define workflow. | + |
Current revision
[edit]
Checklist - Architecture and Design
[edit]
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.
[edit]
Authentication
- 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.
[edit]
Authorization
- 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.
[edit]
Caching
- 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.
[edit]
Communication
- 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.
[edit]
Composition
- 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.
[edit]
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.
[edit]
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.
[edit]
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.
[edit]
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.
[edit]
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.
[edit]
Layering
- 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.
[edit]
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.
[edit]
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.
[edit]
Structure
- 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.
[edit]
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.
[edit]
Validation
- 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.
[edit]
Workflow
- 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.