patterns & practices: App Arch Guide 2.0 Knowledge Base

Checklist - Business Layer

Design Considerations

• A separate business layer is used to implement the business logic and workflows.
• Component types are not mixed in the business layer.
• Common business logic functions are centralized and reused.
• Design reduces round trips when accessing a remote business layer.
• Business layer is not tightly coupled to other layers.

Authentication

• Users are authenticated in the business layer, unless they come from another layer on the same tier to which you are willing to extend full trust.
• Single sign-on is used, if your business layer will be used by multiple applications in a trusted environment.
• The original caller is not flowed to the business layer, unless it’s necessary to authenticate based on the original caller’s ID.
• Trusted sub-system is used for access to back-end services to maximize the use of pooled database connections.
• IP filtering is used when using web services, to only allow calls from the presentation layer

Authorization

• Users are authorized based on their identity, account groups, claims or roles.
• Role-based authorization is used for business decisions.
• Resource-based authorization is used for system auditing.
• Claims-based authorization is used to support federated authorization.
• Impersonation and delegation are not used unless absolutely necessary and the performance trade-offs are well understood.

Business Components

• Business components do not mix data access logic and business logic.
• Components are designed to be highly cohesive.
• Business rules are implemented in business process components to keep business rules separate from business data.
• Volatile business rules are stored in a rules engine.
• Workflow components are used, if the business process involves multiple steps and long-running transactions.

Business Entities

• Appropriate data format is used to represent business entities.
• Domain Model pattern is used for designing business entities, if the application needs to support complex business model.
• Table module pattern is used to design business entities, if the tables in the database represent the business entities.
• Business entities support serialization if they need to be passed over network or stored directly to the disk.
• The Data Transfer Object (DTO) pattern is used, to minimize the number of calls made across tiers.

Caching

• Static data that will be regularly reused within the business layer is cached.
• Data that cannot be retrieved from the database quickly and efficiently is cached.
• Data is cached in ready-to-use format.
• Sensitive data is not cached.
• Web farm deployment scenario considered, while designing business layer caching solution.

Coupling and Cohesion

• There are no circular dependencies between layers of the application.
• The design doesn’t require tight coupling between the business layer and other layers.
• The business layer is designed to be tightly coupled within itself.
• The business layer components are highly cohesive.
• Data access logic is not mixed with business logic in the business components.

Concurrency and Transactions

• The design defines transaction boundaries, so that retries and composition are possible.
• A compensating method to revert the data store to its previous state is used, when transactions are not possible.
• Locks are not held during long-running atomic transactions, compensating locks are used instead.
• Appropriate transaction isolation level is used.

Data Access

• Data access code and business logic are not mixed with the business components.
• The business layer does not directly access the database; instead a separate data access layer is used.

Exception Management

• Exceptions are not used to control business logic.
• Exceptions are caught only if they can be handled
• Appropriate exception propagation strategy is designed.
• Global error handler is used to catch unhandled exceptions.
• The design includes a notification strategy for critical errors and exceptions.
• Exceptions do not reveal sensitive information.

Logging and Instrumentation

• Logging and instrumentation solution is centralized for the business layer.
• System-critical and business-critical events in your business components are logged.
• Business-sensitive information is not written to log files.
• Log failure does not impact normal business layer functionality.
• All access to functions within business layer are audited and logged.

Service Interface

• The service interface is abstracted from business logic changes.
• The service interface does not implement business rules.
• Service interfaces are designed, for maximum interoperability with other platforms and services.
• The service does not make any assumptions on how the service will be used.
• An appropriate transport protocol has been chosen.

Validation

• All input is validated in the business layer, even when input validation occurs in the presentation layer.
• The validation solution is centralized for reusability.
• Validation strategy constrains, rejects, and sanitizes malicious input.
• Input data is validated for length, format, and type.

Workflow

• Workflows are used within business components that involve multi-step or long-running processes.
• Appropriate workflow style is used depending on the application scenario.
• The workflow fault conditions are handled appropriately.
• The Pipeline pattern is used, if the component must execute a specified set of steps sequentially and synchronously.
• The Event pattern is used, if the process steps can be executed asynchronously in any order.

Deployment Considerations

• Business logic is deployed on a physically separate machine, only if it’s really required.
• Message-based interface is used for the business layer, if the business layer is to be deployed on remote tier.
• TCP protocol is used if the business layer must be on a separate physical tier.
• IPSec is used to protect data passed between physical tiers.
• SSL is used to protect data passed to remote Web services.