所谓的 ＤＤＤ无异于将所有的业务抽象到领域层，所有的都是对象，所有的对象对自己负责，具体实现时，我的思路是这样的：
首先对业务领域建模，摈弃以往的以数据为中心的思想，首先不考虑哪些需要持久化，尽管根据业务流程进行建模，建模完成后，到了我们考虑哪些数据需要持久化了。从领域对象中找出需要持久化的数据模型，再次审视所有的业务对象的职责，或者通俗的说 ，方法，把握一个尺度，对于所有与持久化相关的操作，如果是简单的ＣＲＵＤ则放到对应ＤＡＯ中，涉及查询等放到仓储中查询，使用工厂进行对象创建，如对于Ｌａｚｙ－ｌｏａｄ之类的问题则可以通过仓储和工厂解决。大颗粒度操作抽象到对应服务中。最后就是再次在更高的层次审视整个模型，必要时使用Ｆａｃａｄｅ 模式，在系统最上方加一层，如果涉及团队或老系统集成，在必要的Ｃｏｔｅｘｔ中添加ａｎｔｉ－ｃｏｒｕｐｔｉｏｎ层……
望大家指教
说起来感觉自己很容易，真正进行建模了才发现憋了半天也就画了几个类图，仔细一看才发现那些就是需要持久化的实体对象……
我感觉ＤＤＤ重要的还是如何抽象出领域对象，这才是关键，其实谁都有心要ＯＯ，可能否发现系统中的领域模型不是谁都能做的
>实体和服务的职责划分 ，哪些操作要放到实体里，哪些要丢到服务中
这个我在另外一个帖子中也提到:必须判断哪些特征是属于该对象固有基本的；哪些则不是，哪些和应用特征相关的服务性质，比如人存取款这个动作特征，其实和具体应用有关，而不是人对象固有基本的。
这里就有两个极端：一个是将所有操作都放在实体中，如2001年的Jive2.5设计就是这样，最后带来弊端就是每个实体对象很复杂；还有另外一个极端就是实体中没有任何操作，这是MF的批评的失血模型，贫血模型。过去有人当听到MF批评失血模型时，就开始将实体的save等操作放在实体中，这个我个人认为不妥，save属于对象持久化，属于对象生命周期的管理维护动作，一个对象不能自己对自己生命周期进行管理维护，这其实是很正常日常生活常识，我们人都是由父母给予生命的，不可能自己创建自己，万事万物的生命都不是它自己创建的，或它自己来管理维护。
但是，无论哪一种，都和数据库模型毫无关系的，现在又推出一种非数据库，但是也非领域模型的模型设计，他就以网站社区为案例，提出：“我明白Martin在这个主题上的观点,他说要把更多的逻辑关系放到领域模型里,但是如果你的领域模型里不需要任何逻辑,而只是存取数据呢?”
中文翻译：
http://docman.cn/dm/doc.php?id=21
原文网址：
http://thebull.macsimumweb.com/building-a-high-volume-app-without-a-rdms-or-domain-objects/
[该贴被banq于2007年06月27日 10:23修改过]
我个人认为不能因为一个特例就认为这和面向过程相似，面向过程概念很广，并不是每个方面都不好，而是有一个主要缺点，主要缺点我认为就是将业务逻辑放在服务中了，而不是模型中。
将业务逻辑放入服务中缺点很多：不能方便改变前后逻辑执行顺序，过去EJB中Session Bean常被用来实现服务，很多人还是面向过程思维，结果将业务逻辑很自然放到Session bean中，还以Facade模式自我安慰，这样的系统在业务需求变化时，很难敏捷跟上变化，还是一个传统面向过程系统，这些做法受到OO派疯狂批判，最后EJB技术本身成了替罪羊。到了EJB3，如果你将业务逻辑还是放在你的POJO服务类，还不是回到过去？这种现象同样存在Spring等其他框架应用中，Jsp+JavaBeans中更严重，甚至初学者将业务写在Jsp中，这样的系统可以说都是面向过程思维惹的祸。
所以，重要的是程序员自己的编程思想改变，而不是技术平台简单升迁。
[该贴被banq于2007年06月28日 19:03修改过]
[该贴被banq于2007年06月30日 19:49修改过]