业务逻辑层是专门处理软件业务需求的一层，处于数据库之上，服务层之下，完成一些列对Domain Object的CRUD，作为一组微服务提供给服务层来组织在暴露给表现层，如库存检查，用法合法性检查，订单创建。
业务逻辑层包含领域对象模型，领域实体，业务规则，验证规则，业务流程。1：领域对象模型为系统结构描述，包含实体功能描述，实体之间的关系。领域模型处于天生的复杂性:2：领域实体：业务层是一些操作业务对象（BO）的处理。业务对象包含数据和行为，是一个完整的业务对象。其不同于上节架构设计中服务层的简单理解提到的数据迁移对象（dto），对于dto存在数据的，不存在行为，dto是bo（ddd中又称do）的子集，负责与特定界面需求的扁平化实体，dto仅仅是一个数据载体，需要跨越应用程序边界，而业务对象则不会存在复制迁移，往往一个业务对象存在一个或者多个数据迁移对象。3:业务最大的逻辑就在处理一些列现实世界的规则，这也是软件中最容易变化的部分，这里通常会出现我们众多的if-else或者switch-case的地方。也这因为如果说以个人觉得在我们的项目最应该关系和分离需求的层次。4：验证规则：业务规则很大程度上也是对对象的数据验证，验证业务对象的当前数据状态。我觉得在每个业务对象上都应该存在一个对外部对象暴露的验证接口，可以考虑微软企业库的VAB 基于Attribute声明式验证或者上节流畅的验证组件：FluentValidation中的FluentValidation验证组件基于IOC的解耦。
业务层模式：在常见的业务层模式中主要分为过程是模式和面向对象模式。过程模式有是事务性脚本和表模式，而面向对象模式为活动记录模式和领域驱动模式。理论上说事务性脚本模式是最简单的开发模式，其前期投入下，但随着项目周期和复杂度上升明显，而领域模型（DDD）前期投入较大，但是理论上说是随着项目周期和复杂度呈线性增加，当然这些都是理论值。
1：事务脚本模式是业务逻辑层最简单的模式，面向过程模式。该模式以用于的操作为起点，设计业务组件，即业务逻辑直接映射到用户界面的操作。这通常是从表现层逻辑出发，表现层我需要什么业务层提供什么，直到数据层。针对没一个用户的新功能都需要新增一个从UI到关系数据库的分支流程。其使用与逻辑不是很复杂或者变化不大稳定的应用系统开发。其不需要付出与业务无关的额外代价，并且在现代VS之类的IDE帮助下能够很快的进行快速应用开发（RAD）。也由于这种优势，也是其最大的劣势，程序中充满了IF-else，switch-case之类的逻辑或者大量的static的方法，每个功能都是一个程序分支，这对代码无法重用。编码不易于维护，对复杂项目和变化需求不适应。
2：表模式：为每个数据库表定义一个表模块类，包含操作该数据的所有行为方法。作为一个容器，将数据和行为组织在一起。其对数据的粒度针对于数据表，而非数据行，因此需要以集合或者表传递数据信息。表模式基于对象但是完全又数据库驱动开发，在业务模型和数据库关系模型显著差异的情况下，应对需求，并不是那么适合。但是在.net中提供的一些列如强类型DataSet等IDE的辅助下自动生成大量的代码，也是一个不错的选择，因为部分数据库的操作趋于自动化。表模式没太过于关注业务，而是关注数据库表结构。而业务逻辑和领域问题才是软件核心。
3：活动记录模式：一个以数据库表一行Row为对象，并且对象中包含行为和数据的模式方法。其数据对象很大程度的接近数据库表结构。在活动记录模式对象中通常也包含操作对象的CRUD行为，数据验证等业务规则。对于业务不是很复杂，对象关系与关系模型映射不具有很大差异情况，活动记录模式会运用的很好。活动模式比较简单化设计，在上现行的很多如Linq to sql，ActiveRecord框架的辅助下，将针对问题领域不是太过复杂的项目十分有用。但是其模式和数据库表结构的相互依赖，导致若你修改数据库结构，你不得不同时修改对象以及相关逻辑。如果不能保证数据库关系模型和对象模式的很大程度的相似这就进入的困境。
4：领域模型：在前面的几种模式都是项目开始站在了以数据为中心的角度，而不是业务本身的问题领域。而领域模型关注系统问题领域，首先开始为领域对象设计。与活动记录模式来说，领域模型完全站在了问题领域业务概念模型一边，与数据库，持久化完成独立，其推崇持久化透明（POCO）。其可以充分利用面向对象设计，不受持久化机制的任何约束。其实完全又业务驱动出来的。但是其最大的优势如上各个模式一样也是其最大的劣势对象模型和关系模型具有天然的阻抗，我们的领域实体早晚需要映射到持久化机制。还好的是当前有NHibearnate,EF,Fluent NHibearnate这类ORM框架辅助。在DDD中包含UOW，仓储，值类型和聚合根，领域事件，领域跟踪一类的概念，这将在以后具体说明。
模式的选择在与架构师的决定，这也是架构师具有挑战意义的职责，需要根据具体的项目需求，团队，个人等外界因素最终决定，不存在万能的模式，也不存在完美的设计。
