Checklist - Business Layer

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

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.

Last edited Dec 19, 2008 at 7:48 PM by prashantbansode, version 2

Comments

No comments yet.