转载：浅谈领域驱动设计
无意发现一篇文章，写得很不错，来自Anders小明的Blog,原文地址：
http://www.blogjava.net/AndersLin/archive/2009/05/07/269496.html
摘取部分，大家可以去看一下原文
摘录自"Anders小明的Blog"
为何要面向对象？
1. 面向对象是自上而下的开发方法；这种方式对于迭代增进式的结构化过程来说成本是最低的；
2. 数据和业务逻辑的绑定性，采用面向对象容易操作和沟通（即实施成本低），同时有助于区分状态逻辑和任务逻辑；
3. 业务逻辑的差异性，同一个业务逻辑针对差异性数据有区分做法，采用面向对象容易维护；
1. 面向对象是自上而下的开发方法；这种方式对于迭代增进式的结构化过程来说成本是最低的；
2. 数据和业务逻辑的绑定性，采用面向对象容易操作和沟通（即实施成本低），同时有助于区分状态逻辑和任务逻辑；
3. 业务逻辑的差异性，同一个业务逻辑针对差异性数据有区分做法，采用面向对象容易维护；
摘录自"Anders小明的Blog"
生命周期相关的聚合和组合关系。关系数据库中所保存的是系统分解后的表示，即关系被分解了而不是被表达了，外键对数据关系只起到一种约束作用，它对于查询语句的构建并没有直接的影响。所有数据之间的关系都必须在查询的时候明确指定出来，即调用者必须拥有数据关系的知识，而不是数据本身拥有这些知识．在如下的SQL语句中
“select * from a, b where a.fldA = b.fldB and a.fldC = 1 and b.fldD = 2”
其中，a.fldA = b.fldB 可以称为关联条件，而a.fldC=1可以称作是坐标条件。
SQL的复杂性很大程度上来源于我们频繁的需要在各处指定完全一样的关联条件而无法把它们抽象成可复用的组分．在ORM所提供的对象空间中，对象之间的两两关联只要指定一次，就可以在增删改查等各种操作过程中起到作用，特别是在对象查询语句中，可以通过两两关联自动推导出多实体之间的关联关系，虽然推导出的结果未必是最优化的.
摘录自"Anders小明的Blog"
领域模型
概念上，一个领域模型和普通的符合面向对象原则的对象有声明区别：领域模型是业务意义上，承载了业务数据（可以认为所有领域模型是有状态对象），从本质上说它直接来源于现实世界，没有技术层次上的考虑，“符合面向对象原则的对象”是用面向对象方法分析得到的，是基于计算机领域技术的（这样的对象可以是无状态的）；但反过来，符合面向对象的对象不一定反映业务领域的模型。
概念上，一个领域模型和普通的符合面向对象原则的对象有声明区别：领域模型是业务意义上，承载了业务数据（可以认为所有领域模型是有状态对象），从本质上说它直接来源于现实世界，没有技术层次上的考虑，“符合面向对象原则的对象”是用面向对象方法分析得到的，是基于计算机领域技术的（这样的对象可以是无状态的）；但反过来，符合面向对象的对象不一定反映业务领域的模型。
技术上，领域模型是指那些包含需要被透明持久化的属性，以及相关业务逻辑的POJO。一个领域模型包含了这些需要被持久化的业务数据，同时还包含了与之相关所有业务操作（即能操作所有属于本模型生命周期内的模型数据），并且有自己的继承体系。Martin Fowler认为有了这些就可以称为是一个领域模型，因此在其PoEAA中的ORM包含了一些不透明的持久化方案。我认为一个真正的领域模型需要一个透明持久化。
摘录自"Anders小明的Blog"
领域服务的运行模式
简单的说，业务处理将被细化成处理控制器和具体处理器。在这级别，处理对于请求的响应处理已知的有三种模式：
事件模式（Observer Pattern）、职责链模式（Chain of responsibility Pattern）以及数据流模式（Pipes and Filters Pattern）。这几个模式处理的各自不同的场景。其中数据流模式很适合需要处理大量数据的情况。
简单的说，业务处理将被细化成处理控制器和具体处理器。在这级别，处理对于请求的响应处理已知的有三种模式：
事件模式（Observer Pattern）、职责链模式（Chain of responsibility Pattern）以及数据流模式（Pipes and Filters Pattern）。这几个模式处理的各自不同的场景。其中数据流模式很适合需要处理大量数据的情况。
[该贴被oojdon于2009-11-03 21:34修改过]