Architecture and Design Checklist

From Guidance Share

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

Contents 1 Checklist - Architecture and Design 1.1 Design Considerations 1.2 Authentication 1.3 Authorization 1.4 Caching 1.5 Communication 1.6 Composition 1.7 Concurrency and Transactions 1.8 Configuration Management 1.9 Coupling and Cohesion 1.10 Data Access 1.11 Exception Management 1.12 Layering 1.13 Logging and Instrumentation 1.14 State Management 1.15 Structure 1.16 User Experience 1.17 Validation 1.18 Workflow

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.