1. 业务逻辑层：
1) 对象模型和领域模型区别:
对象模型仅是一系列的对象，并不包含模型在设计和实现上的约束。在拥有了一系列相关的类型后也就自然得到了一个对象模型；
领域模型是一个用来实现一系列雪球的对象模型，是针对某个特定文帝领域而设计的，力图对领域中实体与关系中设计的流程和数据进行抽象。
2）BO和DTO的区别：
BO是某个领域实体（即封装了数据和行为的类）的实现，或者是某类辅助类型，用来执行一些特别的计算，是一个可以参与到领域逻辑中的完整对象；
DTO更像是一种值对象，即一系列数据的容器而没有相关的行为；
DTO表示特定领域对象的一个子集，用于专门的上下文中（模型中领域实体类型可能会有多个与之对应的DTO）；
关于BO和DTO的取舍，依实际应用而定（当BO数量已经很多或并不应该仅仅为了设计的赶紧而让对象数字加倍时，BO就是DTO）
3) 业务规则：
业务规则取决于项目的上下文，可能会充满变化。所以业务规则层中，规则应该是一种非常灵活的实现，最好由专门的规则引擎负责。
4）验证：
业务规则很大程度上是对对象的验证；
若有专门的验证层，并让业务对象可选择的支持（如通过接口），这个设计将会非常不错。每个业务对象都暴露出一个接口，让其他对象可以检查该对象是否满足必要的规则。
5) 横切组件：
横切组件能够有效地表示业务流程并在内部管理业务对象的实例，如：转发某类消息、自动计算某些信息、将核心系统和现有子系统（可能运行于不同平台上）进行集成
6）Layer vs Tier：
Layer用来表示系统中完成指定任务的逻辑部分，一般用来组织代码；
Tier指代码运行的位置，用来表示系统中物理上的硬件和软件，由执行同样功能的一台或多台服务器定义
7）物理层：
定义：一个层表示一个需要穿过的边界，这个边界可能是进程边界或计算机边界；
性能：一个估算比例是穿越进程边界要比进程内部调用慢100倍左右，或需要通过网络访问，还要更慢一些；
优缺点：多物理层会降低整体性能，并增加整体复杂性；但可以增强安全性、可伸缩性以及容错性。
8）业务层和其它层:
通常应该尝试把所有事情都放在业务逻辑层中完成，除了创建、读取、更新和删除操作以及界面的调整之外。分算在表现层和数据访问层中的逻辑有可能只是出于性能方面的考虑才进行的重复。
数据格式化：存放原始数据，在需要时再格式化
CRUD操作：复杂的逻辑应该属于业务对象的行为，数据访问层应该紧紧用来处理数据库的相关操作，甚至不了解业务实体的存在
存储过程：应该把存储过程仅仅当做一个数据库工具，用来返回并更新数据，而不是作为业务逻辑的表达工具。
2. 在开始组织业务逻辑时，仅有一个重要决策需要考虑：那就是选用面向对象设计还是过程式设计
3. 事务性脚本模式：
关注点：在于用户通过表现层所能执行的操作，并为每个操作编写一个专门的方法（这个方法就叫事物脚本）
使用场景：适用于那些业务逻辑非常简明直白，且最好不打可能改变的简单场景中
优势：简单；
劣势：代码重复
实战：可以结合使用命令模式
4. 表模块模式：
使用场景：不需要太多抽象，且数据模型和对象模型之间没有太大差异，实体甚至可以直接映射到数据库表上时
方法：为每个数据表定义一个业务组件（这个组件叫做表模块类，它包含操作于该数据表的全部代码）
使用：数据访问层和业务层间用DataSet，业务层和表现层间用DataTable（减少数据传输）
优势：各种IDE均对其提供了很丰富的支持；无论底层数据源是什么，对于同一功能都会得到同样的表模块类
劣势：IDE生成的代码类似于一个黑箱
基于面向过程，使用事务脚本还是表模块：鉴于vs的强大功能，.Net中一般使用表模块（别的平台可能有所不同）
实战：
1）表模块组件中成员一般应该是实例成员
2）表数据网关模式
强类型DataSet？？？？
5. 活动记录模式：
定义：指一个封装了数据库表或试图的一行的对象，对象中可以同时包含数据（列中的值）和行为（包含逻辑的方法）
注意：活动记录对象的结果应该尽可能地接近于相关联的数据表结构
场景：只要领域逻辑不是太复杂，且与数据模型之间不需要很复杂的映射关系。（如很多web站点）
优势：简单和框架（LINQ-to-SQL和Castle ActiveRecord）
劣势：若不能保证对象模型和数据模型之间足够类似，数据映射工作麻烦
实战：
行数据网关（linq-to-sql的DataContext）
6.领域模型模式：
关注点：关注于系统的期待行为以及系统正常工作所需要的数据流
场景：业务逻辑的重用性需求是判断是否值得使用领域模型的一个关键参数
优势：概念是用类来建模，充分利用了面向对象设计的优势
劣势：对象和关系型数据库之间的不匹配
工具：NHibernate、Entity Framework
实战：