要领域模型干嘛？

举个例子

class User {
    int id;
    String name;

    // getter/setter
}

有这样一个实际场景。姓名为aaa用户改把名字修改成了bbb
ok。那么我们做的是什么呢？
1. 我们得到用户aaa
 

    User u = ...;   // ... 为一些的逻辑 
 

2. 调用 u.setName(bbb); // 已经修改用户名了。

3. 把 u 持久化。

那么，我想说的是：3 是属于业务么。到2的时候，我们的业务其实已经达到了。
如果我们有一台永不down机的服务器。无限大小的内存。那么，我想大家根本就不会有3这个步骤地出现了。
所以，3这个步骤，完全可以看成是为了业务而做的善后工作。
但是，很不幸，我们没有一台这样的服务器。所以，采用了3。
那么，3应该是User的某个方法吗？ u.save()？

记得在大家都用jdbc的时代。为了维护性。写了dao。目的是容易拓展不同的数据库。所以，我们有了UserDao.save(User u); 那当时，我们为什么没有写在User里面。把User做成一个接口。然后有MysqlUser, OracleUser呢？我觉得还是维护性问题以及这个持久化也不属于领域业务。

现在大家有了hib/jpa了。好像dao也不再是以前的dao了。于是，我们要充血，我们要把所有的方法都放到User中。那么，哪天我们用自己的文件系统持久化对象或者用对象数据库持久化。你会发现dao还是这么有用。那时候，我们可能是：RelationDBDao, ObjectDBDao, MyFileSystemDao。

于是有人说了，我们不要完全的贫血，也不要完全的充血。我们应该把属于业务的方法，放到User中。而属于持久化的方法，我们不能放到里面。ok！既然这么说了。那我们以后严格按照这个原则走了。以后我们就这么干。我们可以不要service了。我们有Pojo 和 dao 就可以了。
但是，真的就可以了么？

以前在讨论面向对象编程。后来大家开始讨论面向接口编程。接口就是契约。我们把公共的东西抽出来，形成了接口。然后，把公共部分的实现写成抽象类。不同的实现在写不同的class以及实现。

那么，回到上面。pojo何尝不是我们的公共契约呢？它里面定义的最基本的内容何尝又不是我们最长久保持不变的东西呢？所以，这个部分我们就应该让他贫血。而把真正与之相关的业务操作抽象出来放到service中。

如果说在2个系统里面，记住是2个系统。但是只有1个系统进行数据的持久化。但是2个系统完全不是相同的业务。2个系统通过某种方法进行联系。webservice也好，rest也好，tcp/ip也好，等等等等。但是他们却有着不同的一套业务。在系统1种，用户有一个验证权限机制是：用户不能为 男性。而系统2种是不能为 女性。那么，你们觉得把验证方式写在User里面合适么？

也许有人会说，我们完全可以：

System2User u = new System2User(System1User);

那么我想说，如果System1User的结构变化了呢？

所以，service还是很需要的。pojo就让他贫血好了。

c#不了解。但是如果采用minix(我也不知道有没有打错)的这种方式，个人感觉只是一个小技巧而以。让domain拥有了这个namespace的其他一些方法。其实我也可以Service里面把这些方法都写好了。然后在xxx(Domain domain); 只是没有domain.xxx() 好看了而以。

采用了service和贫血domain同样也可以有很简单的模型。和较强的测试性。

个人感觉要谈 ddd， 至少要把 Martin Flower， Eric Evan，Dan North 的书 http://domaindrivendesign.org/books/ 吃透了，  再看一下
http://dddsample.sourceforge.net/ 丰富丰富理论， 这样大家有共同的认识后再讨论， 否则多说无益

我还是坚持用贫血的对象，1：大家都熟悉理解，降低开发维护成本，2：充血对象怎么设计，怎么平衡，大家没有一致观点，弄不好出一个不论不类、难于维护的东西。简单实用、结构清晰、容易维护就是好的。管这么多干嘛呢。说实在的，逼迫下面的程序员多写点注释、把代码写的清晰简单点也比这个强

太极有阴阳之说，贫血，充血都有道理，根据情况而定吧。有些情况下贫血是好用的，有些可能要用到充血模型

挺热闹，不知有哪位弟兄在实际开发当中完全贯彻了DDD？结合实际案例与经验谈谈。

从面向对象的角度来讲，domain里面可包含的东西应该更多 除了crud 有些业务方法甚至也可以写到domain中，以达到更好的代码reuse
但是如果脱离了实际的语言特性来讨论domain应该是做成什么样子是没有意义的

就javaEE来讲，要把dao service等操作整合到domain中会使domain越来越大 越来越臃肿 可维护性一泄千里

->原子组成分子、分子组成微量物质、微量物质组成细胞、细胞组成各种有机活动体、

->各种有机活动体组成 各种有特殊功能的器官、
->器官组成一个活动的生命体

->生命体（比如人）组成某个群体
->某几个群体组成一个集团
->某几个集团组成一个组织
->某几个组织构成一个国家-> 某几个国家构成全世界
->不同的美丽世界构成 这个美丽的地球

-> 但地球 对于宇宙来说 只是一个"分子" 又回到原点。

-> 领域模型 无非就是 这种模型

技术没有好坏之分吧。

不管充血还是贫血模型，对最终的应用系统来说，总归是看不见摸不着的。

说到底不过是业务逻辑写在哪里的问题，有什么大区别么？

不过，对于集中的充血模型，对测试来说的确是太有益处了，如果真的有一天我能做到一个充血模型的项目，我愿意去做测试。

另外更加体现了文档和注释的重要性。

我觉得领域模型是设计层面的东西（概要设计），代码组织是实现层面的东西（也可以说详细设计）。领域对象也没必要非得像传统上那样映射到表或者记录，领域模型是来源于领域逻辑不是数据库模型