This project is read-only.

Designing Business Layers

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


The chapter walks you through the design process of business layer and key guidelines for designing the business layers and the business components. These guidelines cover the important aspects you should consider when designing a business layer and business components. The guidelines are organized by category and consist of guidelines for designing business layers, and implementing appropriate functionality such as security, caching, exception management, logging, and validation. These represent the key areas for business layer design where mistakes are most often made.


Business Components

Following are the main components within the Business layer, this section explains what are roles and responsibility of each.
  • Application Facade. (Optional). Use to combine multiple business operations into single messaged based operation. You might access the application façade from the presentation layer using different communication technologies.
  • Business components. After the required data is collected by a user process, the data can be used to perform a business process. Many business processes involve multiple steps that must be performed in the correct order and orchestrated. Business workflows define and coordinate long-running, multi-step business processes, and they can be implemented using business process management tools.
  • Business entity components. Business entities are for passing data between components. The data is used to represent real-world business entities, such as products or orders. The business entities that are used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order.
  • Business workflow. After the required data is collected by a user process, the data can be used to perform a business process. Many business processes involve multiple steps that must be performed in the correct order and orchestrated. Business workflows define and coordinate long-running, multi-step business processes, and they can be implemented using business process management tools.


While designing a business layer you need to take into account the approach towards designing the business layer and the main components like business components, business entities and business workflow components. This section briefly explains the main activities involved in designing each of the component and overall business layer.

Business Layer – When designing the business layer following are the key activities that you need to perform.
  • Identify the consumers of your business layer
  • Determine how you expose your business layer
  • Determine security requirements of your business layer
  • Determine your validation requirements and strategy for business layer
  • Determine caching strategy for your business layer
  • Determine exception management strategy for your business layer

Business Components – When designing the business components following are the key activities that you need to perform.
  • Identify different types of business components
  • Determine application design considerations
  • Identify transactional requirements
  • Identify how business rules are handled
  • Identify patterns that fit the requirements

Business entities – When designing the business entities following are the key activities that you need to perform.
  • Identify common data formats for business entities
  • Determine how data will be used in the application
  • Choose your approach for managing rules
  • Optionally choose your design for custom objects
  • Optionally determine serialization support

Business Workflow – When designing the business workflow following are the key activities that you need to perform.
  • Identify workflow style using scenarios
  • Choose an authoring mode
  • Determine how rules will be handled
  • Choose a workflow solution
  • Design business components to support workflow

Design Considerations

When designing a business layer the goal of a software architect is to minimize the complexity by separating things into different areas of concern. For example, business processing, business workflow and business entities all represent different areas of concern. Within each area the components you design should focus on that specific area and should not mix code from other areas of concern.

When designing business layer, consider following guidelines:
  • Evaluate if you need a separate business layer. It’s a good idea to separate out your business layer where possible from maintainability of your application
  • Identify responsibilities of your business layer. Use business layer for processing complex business rules, transforming data, applying policies, and validation.
  • You should not mix different types of components in your business layer. Use business layer to decouple business logic from presentation and data access code, and to simplify testing of business logic.
  • Reuse common business logic. Use business layer to centralize and allow for reuse of common business logic functions.
  • Identify the consumers of business layers. This will help you determine how you expose you business layer, for instance if your business layer is going to be used by your presentation layer and also some external application you might choose to expose your business layer via a Web Service.
  • Loosely couple your business layer. Use a message-based interface in a stateless business layer, for example in a Web application. Use abstraction when possible.
  • Reduce round trips when accessing remote business layer. If you are using a message-based interface, consider using coarse-grained packages for data such as a Data Transfer Object. In addition, you should consider implementing a remote façade for the business layer interface.
  • Avoid tight coupling across layers. You should use abstraction to provide an interface into the business layer. The abstraction can be implemented using public object interfaces, common interface definitions, abstract base classes, or messaging. For web applications you should consider a message-based interface between the presentation and business layers.

Business Layer Frame

Category Common Issues
Authentication Using authentication in business layer when not needed.
Designing custom authentication mechanism.
Failing to use single-sign on where possible
Authorization Incorrect roles granularity
Using impersonation and delegation when not required.
Mixing authorization and business processing code.
Business Components Overloading business components
Mixing data access logic within business components.
Not considering message based interfaces to expose business components.
Business Entities Using Domain Model when not required
Choosing incorrect data format for your business entities.
Not considering serialization requirement.
Caching Caching volatile data
Caching too much data in business layer
Failing to cache data in ready-to-use format.
Coupling and Cohesion Tight coupling across layers.
No clear separation of concerns within business layer.
Failing to use message based interface between layers.
Concurrency and Transactions Not protecting concurrent access to static data.
Not choosing the correct data concurrency model.
Long running transactions that hold locks on data.
Data Access Accessing database directly from business layer
Mixing data access logic within business components.
Exception Management Revealing sensitive information to the end user.
Using exceptions for application logic.
Not logging enough details about the exception.
Logging and Instrumentation Failing to add adequate instrumentation to business components.
Failing to log system and business critical events.
Not suppressing logging failures.
Service Interface Breaking the service interface
Implementing business rules in service interface
Failing to consider interoperability requirements
Validation Relying on presentation layer validation.
Not validating for all the parameters like “Range” , “Type” and “Format”
Not reusing the validation logic
Workflows Not considering management requirements.
Choosing the incorrect workflow pattern.
Not considering exception states and how to handle them


Designing an effective authentication strategy for your business layer is important from security and reliability of your application. Failing to design a good authentication strategy can make your application vulnerable to spoofing attacks, dictionary attacks, session hijacking, and other attacks.

When designing Authentication, consider following guidelines:
  • Avoid authentication at business layer when the business layer is on the same tier and it trusts presentation layer.
  • Authenticate users if the business layer is deployed on a separate tier or is shared by other applications.
  • Consider using single sign-on on in a trusted environment, when supporting multiple applications.
  • Evaluate if you need to flow the caller's identity to the business.
  • Use trusted subsystem to access back-end services to maximize the use of pooled database connections.
  • Avoid designing custom authentication mechanism.


Designing an effective authorization strategy for your business layer is important from security and reliability of your application. Failing to design a good authorization strategy can make your application vulnerable to information disclosure, data tampering, and elevation of privileges.

When designing Authorization, consider following guidelines:
  • Consider designing roles upto appropriate granularity.
  • Protect resources by applying authorization to callers based on their identity, groups, or roles.
  • Use role-based authorization for business decision.
  • Use resource-based authorization for system auditing.
  • Use claims-based authorization when you need to support federated authorization based on a mixture of information such as identity, role, permissions, rights, and other factors.
  • Avoid using impersonation and delegation
  • Avoid mixing authorization with business processing.

Business Components

Business components implement business rules in diverse patterns and accept and return simple or complex data structures. Your business components should expose functionality in a way that is agnostic to the data stores and services needed to perform the work, and should be composed in meaningful and transactionally consistent ways. Hence designing business components is an important task, if you fail to design business components correctly, you might end with un-maintainable code.

When designing business components, consider following guidelines:
  • Avoid overloading of components
  • Avoid mixing data access logic within your business components
  • Design components to be highly cohesive
  • Consider using message based communication for invoking business components.
  • Ensure that processes exposed through service interfaces are idempotent
  • Make sure the data format for input and output to business components is consistent.
  • Expose functionality in a way that is agnostic to the data stores and services needed to perform the work to achieve a loosely-coupled design.
  • Consider using business process components to implement your business rules.
  • If your application has volatile business rules, store them in rules engine.
  • Consider workflow components when the process involves multiple steps and long-running transactions.
  • Consider using sufficient and appropriate management instrumentation within the components.

Business Entities

Business Entities stores data values and exposes them through its properties; it provides stateful programmatic access to the business data and related functionality. Hence designing or choosing appropriate business entities is important for making your business layer performant and efficient

When designing business entities, consider following guidelines:
  • Avoid using domain model for designing business entities when not necessary.
  • Choose appropriate data format for your business entities.
  • Consider serialization requirement for your business entities.
  • Consider using light weight domain object to represent the business entities.
  • Consider Table Module pattern to design your business entities when tables in the database represents business entities.
  • Consider minimize the number of calls made across physical tiers. For example use the Data Transfer Object (DTO) pattern.


Designing a good caching approach for your business layer is important for performance and responsiveness of your application. Use caching to optimize reference data lookups, avoid network round trips, and avoid unnecessary and duplicate processing. To implement caching you need to decide when to load the cache data. Try to load the cache asynchronously or by using a batch process to avoid client delays.

When designing caching, consider following guidelines:
  • Evaluate the amount of data being cached at business layer, caching too much data might be counter productive
  • Cache static data that will be regularly reused within the business layer.
  • Consider caching the data that cannot be efficiently retrieved from the database.
  • Consider caching data in ready-to-use format in business layer.
  • Avoid caching sensitive data, and if you need to design for protecting the sensitive data in cache.
  • Consider web farm deployment when designing caching solution for business layer.

Coupling and Cohesion

When designing components for your business layers it is important that the components are highly cohesive and loose coupling is used across layers. This helps in improving scalability of your application.

When designing for coupling and cohesion, consider following guidelines:
  • Avoid tight coupling across layers, Business Layer should know only about the layer below (Data Access Layer) and not the layer above (Presentation Layer or External Applications accessing Business layer directly).
  • Use a message-based interface for your business layer.
  • Design your business layer components to be highly cohesive.
  • Avoid mixing data access logic within your business components.

Concurrency and Transactions

When designing for concurrency and transactions it is important to identify the concurrency model you want to use and determine how transactions will be managed. For concurrency you can choose between an optimistic model or an pessimistic model.

When designing for concurrency and transactions, consider the following guidelines:
  • If you have business critical operations, consider wrapping them in transactions.
  • Use connection-based transactions when accessing a single data source.
  • Use transaction scope (System.Transaction) to manage transactions that span multiple data sources.
  • Consider transaction boundaries, so that retries and composition are possible.
  • Where you cannot use transactions, implement compensating methods that revert the data store to its previous state.
  • Avoid holding locks for long time – for example when using long-running atomic transactions.
  • Consider compensating locks for long running transactions.
  • Consider whether you will use optimistic or pessimistic locking.
  • Choose appropriate transaction isolation level

Data Access

Designing an effective data access strategy for your business layer is important from improving maintainability and separation of concerns.

When designing data access, consider the following guidelines:
  • Avoid mixing data access code within business components.
  • Avoid directly accessing database from business layer
  • Consider using separate data access layer for accessing data base.

Exception Management

Designing an effective exception management solution for your business layer is important from security and reliability of your application. Failing to do so can make your application vulnerable for DoS (Denial of Service) attacks and also might end up revealing sensitive and critical information about your application. Raising and handling exception is an expensive operation, so it’s important the design also takes into account the performance considerations.

When designing exception management, consider following guidelines:
  • Do not use exceptions to control business logic.
  • Differentiate between boundary and internal exceptions.
  • Centralized your approach for handling boundary exception.
  • Consider if you need to transform exception at the boundary.
  • Design appropriate exception propagation strategy.
  • Design strategy for handling unhandled exceptions.
  • Design appropriate exception logging strategy.
  • Design appropriate notification strategy for critical errors / exceptions
  • Do not reveal sensitive information.

Logging and Instrumentation

Designing a good logging and instrumentation solution for your business layer is important from security and reliability of your application. Failing to do so can make your application vulnerable repudiation threat where users deny their actions. Log files may be required in legal proceedings to prove the wrongdoing of individuals. Generally, auditing is considered most authoritative if the audits are generated at the precise time of resource access and by the same routines that access the resource.

When designing logging and instrumentation, consider following guidelines:
  • Centralized your logging and instrumentation solution.
  • Choose appropriate logging sink.
  • Design your business components to instrument system and business critical events.
  • Audit and log access within business layer.
  • Do not log business sensitive information in the log files.
  • Ensure that a logging failure does not impact normal business layer functionality.

Service Interface

When designing a service interface you need to consider granularity of the service, interoperability requirements.

When designing service interface, consider following guidelines:
  • Design services interfaces such that changes to the business logic do not affect the interface.
  • Consider implementing multiple service interfaces if the business logic may be accessed in different ways by different clients.
  • Consider implement caching, mappings, and type conversion in the interface if required by the component.
  • Do not implement business rules in a service interface.
  • Use standard formats for parameters to enable maximum compatibility with different clients.
  • Design service interfaces for maximum interoperability with other platforms and services.
  • Choose appropriate technology for implementing your services.
  • Choose appropriate transport protocol, message formats etc for your services.


Designing an effective validation solution for your business layer is important from security and reliability of your application. Failing to do so can make your application vulnerable for cross-site scripting, SQL injection, buffer overflows, and other input attacks. The main issue with validation is that there is no definitive answer for what is a valid input or for malicious input. Adding to this difficulty is that what your application does with this input influences the risk of exploit.

When designing validation solution, consider following guidelines:
  • When designing validation solution, assume all input is malicious.
  • Validate all input and method parameters in business layer, even when input validation is being done in the presentation layer.
  • Centralize your validation approach, if it can be reused.
  • Choose appropriate validation techniques.
  • Constrain, reject, and sanitize your input.


Workflow components would only be used when your application needs to support a series of tasks that are dependant on processing information. That information can be anything from data checked against business rules to interaction from a human. When designing workflow components it’s important to consider management of the workflow and the options that are available.

When designing workflow, consider the following guidelines:
  • Implement workflows within components that involve a multi-step or long-running process.
  • Handle fault conditions within workflows and expose suitable exceptions.
  • If you need a specified set of steps that the component must execute sequentially and synchronously, consider using the pipeline pattern.
  • If the process steps can be executed asynchronously in any order, consider using the event pattern.
  • Use Windows Workflow to simplify development of workflows that automatically support secure, reliable, transacted data exchange, a broad choice of transport and encoding options, and provide built-in persistence and activity tracking.
  • Use BizTalk Server 2006 if you need to interact with non-Microsoft systems, perform EDI operations, or require very complex orchestrations.
  • Use MOSS only if your business layer is confined to a single SharePoint site and does not require access to information in other sites.

Deployment Considerations

When deploying a business layer the goal of a software architect is to consider the performance and security issues in the production environment.

When deploying business layer, consider following guidelines:
  • Locate business layer on the same tier as presentation layer to improve application performance.
  • If you need to support remote business layer, consider using TCP protocol to improve performance of the application.
  • Locate the business layer on the same physical tier as the other application layers to maximize performance.
  • Use IPSec to protect data passed between physical tiers for all business layers for all applications
  • Use SSL to protect calls from business layer components to remote Web services

Pattern Map

Category Relevant Patterns
Authentication Direct Authentication
Brokered Authentication
Federated Authentication (SSO)
Authorization Role Based Authorization
Resource Based Authorization
Claims Based Authorization
Trusted subsystem
Impersonation and Delegation
Business Components Transaction Script
Work Unit
Application Façade
Chain of Responsibility
Business Entities Entity Translator
Domain Model
Table Module
Caching Cache Dependency
Coupling and Cohesion Adapter
Dependency Injection
Concurrency and Transactions Coarse Grained Lock
Implicit Lock
Optimistic Offline Lock
Pessimistic Offline Lock
Transaction Script
Capture Transaction Details
Exception Management Exception Shielding
Logging and Instrumentation Provider
Service Interface Service Interface
Service Layer
Workflows Data-driven workflow
Human workflow
Sequential workflow
State-driven workflow

Pattern Description

  • Application Façade – Centralize and aggregate behavior to provide a uniform service layer.
  • Brokered Authentication – Authenticate is performed against a broker, which provides a token that is used for authentication when accessing services or systems.
  • Capture Transaction Details – Create database objects, such as triggers and shadow tables, to record changes of all tables belonging to the transaction.
  • Chain of Responsibility – Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.
  • Cache Dependency – Uses external information to determine the state of data stored in a cache.
  • Coarse Grained Lock – Used to lock a set of related objects with a single lock.
  • Command – Encapsulate request processing in a separate command object with a common execution interface.
  • Dependency Injection – Use a base class or interface to define a shared abstraction that can be used to inject object instances into components that interact with the shared abstraction interface.
  • Direct Authentication – Authenticate is done directly against the service or system that is being accessed.
  • Domain Model –** Create a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.
  • Entity Translator – Implement an entity translator object that transforms message data types to business types for requests and reverses the transformation for responses.
  • Exception Shielding – Used to filter exception data that should not be exposed to external systems or users.
  • Façade – Provides a unified interface to a set of operations to reduce coupling between systems.
  • Federated Authentication – Uses a form of brokered authentication to support Single-Sign-On (SSO) against multiple services or systems.
  • Implicit Lock – Uses framework code to acquire locks on behalf of the code accessing shared resources.
  • Optimistic Offline Lock – Used to validate that changes by one session don’t conflict with changes made by another session.
  • Pessimistic Offline Lock – Used to prevent conflicts by forcing a transaction to obtain a lock on data before using it.
  • Provider – Implement an API separate from the API itself allowing any custom implementation to be seamlessly plugged in.
  • Service Interface – Represents a programmatic interface that systems used to interact with other systems.
  • Service Layer – Represents and architectural design pattern where the service interface and implementation is grouped into a single layer.
  • Table Module** – Create a single instance that handles the business logic for all rows in a database table or view.

Additional Resources

Last edited Sep 11, 2008 at 1:49 AM by prashantbansode, version 2


No comments yet.