基于DDD项目的设计总结

“是否有aggregate的概念”和“domain和repository是否分离”没有必然联系吧。

repository也可以为超过一个domain服务的。

不如先把业务逻辑界定一下，不同人理解的业务逻辑都不太一样的。

我手打一下DDD中文版（Eric Evans著，陈大峰、张泽鑫译）109页的一段关于仓储（Repository）的介绍吧（也有可能我会错你的意了，看看无妨）：

之所以有PersonDomainModel是因为业务上需要将Person和Bank封装在一起。 


贴的图是描述项目设计的的总体层次结构，不完全是在描述领域建模部分。

对于你所说的，修改之后的在Repository里面的更新优化问题，你可以应用DirtyMark设计模式。Hibernate, J2EE都是在内部应用了类似的东西。

这个要在Person，Bank上分别的，而不是在PersonDomainModel，按照你的设计。

嘿嘿，还真有，见我附件，不但不反对，还告诉了我们判断该不该这样做的标准。我是不是很土鳖阿...这么较真。
主要是因为我这几天也在学习这方面的东西，早上泛读了下精简版DDD。

看样子本版一些人都把领域模型(Domain Model)直接理解成DDD里的Entity的集合了，当然也有可能是我误会了，估计是OO影响的,我觉得这样不妥.OO里，方法是二等公民，必须依附到一个Object，现在世道变了，方法以及方法所表现的逻辑也要当一等公民，函数式编程这不成潮流了吗，如果从这个角度看，早些年AOP的流行也潜在反映了这个诉求:我们要更多的手段来操作一些逻辑！其实回顾一下就知道，OO就是个手段，我们组织问题域信息的手段，在结构化编程后期，问题域已经复杂到我们难以搞定的程度，这时候OO逐渐流行。既然是个手段，没必要抱死不放吧。从这个意义上来说，讨论贫血模型还是充血模型好，我觉得没太大意义。大家都是反映域模型，当前条件下哪个更方便就用哪个，被必要弄出气宗剑宗看谁是正宗的戏来。

我从DDD上看到的，OO只不过是实现他的核心"Domain Model"的一种工具，这个我们一会儿用UML一会儿用草纸记录的不停交流的东西才是他的核心。

现在换一个方式说，你说新增删除在大多数情况下算不算域逻辑？如果算的话，按照你的想法，是不是person也弄几个person.create,person.delete方法？

这么做有一个问题，就是，没有办法作Lazy Loading来提高性能了，因为你都依靠Repository来做跟底层DAO打交道了！

我理解的对不对？

ORM框架里确实没配Lazy Loading。