Architecture and Design Checklist

From Guidance Share

(Difference between revisions)
Jump to: navigation, search
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

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.
Personal tools