业务逻辑层简介
上图的粗黑色边框的部分就是业务逻辑层，可以包含下面的内容：
- application facade应用外观。这个可选的组件为业务逻辑组件提供一个简单的接口，通常会将多个业务操作合并为一个操作，使得业务逻辑层更容易使用。可以减少依赖，因为外部调用者不需要知道业务逻辑组建的实现细节和他们之间的关系。
- 业务逻辑组件。在任何应用中，业务逻辑的定义都会集中在获取数据、处理数据、传输数据，管理应用的数据、业务规则和策略，保证数据的一致性和合法性。为了最大化的重用，业务逻辑组件不应该包括任何行为。业务逻辑组建可以分为下面的两个目录。
- 业务工作流组件。在UI从用户处收集需要的数据并且传递给业务逻辑层之后，应用将使用这些数据实现业务功能。
- 业务实体组件。业务实体，也被叫做业务对象，代表真实世界的元素，例如：客户和订单。存储数据，暴露属性。
通常的设计考虑
- 在设计业务逻辑层的时候，通过将不同的任务分离到不同的关注点领域，软件架构的目标已经被最小化复杂性。例如：代表不同关注点领域的处理业务规则的逻辑，业务工作流，业务实体。在每一个领域，组件的设计应该集中在该领域，不应该包括其他领域的相关代码。可以参考下面的原则：
- 决定你是否需要独立的业务逻辑层。使用独立的业务逻辑层对于提高应用的可维护性是一个好主意。例外的情况是除了数据验证，没有其他的业务逻辑。
- 确定业务逻辑层的职责和消费者。可以帮助你决定业务逻辑层必须要做什么，如何暴露业务逻辑层。使用业务逻辑层处理复杂的业务，传输数据，应用策略，和数据验证。如果你的业务逻辑层可能会被外部的应用使用，考虑使用服务形式暴露业务逻辑层。
- 在业务逻辑层不要混合其他组件。避免将表现层和数据访问层代码放在业务逻辑层，从表现层和数据访问层解耦业务逻辑，可以简化业务逻辑的测试性。使用业务逻辑层集中管理业务逻辑，可以提供可重用性。
- 访问一个远程的业务逻辑层的时候减少往复。如果业务逻辑层部署在独立的物理层，考虑实现消息为基础的远程application facade，或者是服务层，考虑将细粒度的操作组合成粗粒度的操作，例如： Data Transfer Objects（DTO）。
- 避免层之间的紧耦合。为业务逻辑层创建接口的时候使用抽象来最小化耦合。抽象的技术包括：使用公共的对象接口，通用的接口定义，抽象基类，消息。对于web应用来说，考虑在表现层和业务逻辑层之间使用消息为基础的接口。
特定的设计问题
在开发和设计的过程中，总会有一些常见的问题。这些问题在设计中可以分为不同的领域。下面列出常见的一些领域；
- authentication用户验证
- authorization用户授权
- caching缓存
- coupling and cohesion耦合和内聚
- exception management异常管理
- logging，auditing，and instrumentation日志，审计，性能仪表
- validation数据验证