Architecture and Design Checklist

From Guidance Share

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.