Domain Object贫血vs富血(DDD)和spring roo到ruby的扯淡

比如GIS，点线面class本身承载数据和包含很少的自身的方法，而空间运算都是放在算法逻辑中，而不是数据类中，这样的结构很清晰，复用性也很强
而DAO就是典型的Dao.save(X|Y|Z),这样的结构也很清晰
所以逻辑放在那个地方取决于应用的特性
而电信设备数据系统就是fn(n*A，m*B)->C，D这种特性的逻辑很多，所以service抽出来是更合理的设计

DDD不是一门纯粹的软件设计学问，还是一个软件过程理论。做DDD，前提是要与领域专家充分交互，共同给领域建模，再把领域模型与代码绑定。 DDD也不一定非要用面向对象的方式建模，还可以用建规则模型，数学模型等，只不过面向对象在大部分情况下是最容易建模的。脱离了领域，程序员看到的都是技术问题，是不可能实现DDD的。DDD并不违反面向对象，面向对象要求类要单一职责，所以不应该出现所谓的“充血模型”，一定类只做它该做的事，只会恰到好处，不会血多到要涨。如果一个类太复杂，太大，那说明模型上有些地方要更加的细化了，对应的代码也要更加细化，职责重新划分。DDD也是要迭代中进行的，模型要不断完善，代码也要跟着不断完善。

其实我和你的观点基本上是一致的。我也是想知道搞DDD这帮人是怎么弄的。

你说的没错，但是我们现在想知道在java中，DDD如何具体的落地。而不是想听到高谈阔论，大谈理论。如service层这些要不要，在应用中的架构是怎么样的？用到哪些技术，如spring roo.对于复杂的业务，如多个domain的互相调用协调是如何处理的？在应用DDD中，会出现什么样的问题?以后维护会不会方便。。。

哎，看了楼主的介绍我觉得，楼主对领域驱动设计认识似乎是有问题的，而且我感觉基本上很多人都是存在这样的一个误区。

认为service和entity和DAO合并在一起，就是领域驱动了，比如之前是
Student,StudentDAO(或者泛型DAO),StudentService现在只有一个Student来干所有的事情。

我觉得持有这种观点的人是对DDD的理解有问题的，DDD中最为突出的5辆马车，Entity，Value Object，Factory，Service，Repository，这里可是也有entity也有vo，也有service的。只此一例来证明楼主对DDD的理解有偏差。

说java中做不了DDD，这种话本身就是一种不负责的话。xxx当年还吹嘘过各种各样的技术。都是浮云，做一个负责的人吧。

我承认我对DDD了解不深。那么，DDD应该是吧数据和逻辑放在一起吧？service层应该不管逻辑的事吧，应该只是浅浅的一层。那么dao,service是可有可无吧，从spring roo可以看到一斑。如果你有DDD实践经验，那么你认为DDD在国内是否已经成熟，是否可以在实际的项目中推广了？推广的难度是什么？为什么大家还在用贫血的模式？

哈哈，那么说ruby可有可无了。

在贫血模型周围的框架是用什么编的？

我正在我们公司推进DDD。关于技术实现，我觉得问题不大。想想前人当年没有hibernate, spring等现代化工具时，就能做到，我们现在有更多的选择，不可能做不到的。

一般应用DDD，要对分层，从上到下依次为 用户界面层 -> 应用层 -> 领域层 -> 基础设施层。

你说的service层估计指的是应用程，这一层把用户输入数据转化为领域认识的数据，把领域返回的数据变成用户界面用的数据，这一层知道哪些用户操作执行哪些领域操作。

领域层，就是比较纯的面向对象方式组织的代码了，你说的多个领域对象之间协调是很自然的事情，应该不会有问题。为了减少技术框架对实现领域带来的限制，尽管我们使用hibernate, 但是我打算彻底分离实体和数据库表映射的职责。也就是说，一个实体，就是代表了一个领域对象，而不是一张数据库的表，不作为hibernate的表映射类，不打@javax.persistence.Entity。而映射表的类，放到基础结构层。spring的话，对领域的侵入性相对比较小，只是会因为要注入依赖，而给类添加了一些看起来像关联关系的域，不过只要分清楚，还可以接受。我已经在我们的应用的一小部分应用了这一方式，没有什么问题，后面打算大规模推广。

我深刻的体会到，领域模型里的实体并不和数据库的表有着简单的一对一映射关系。一个实体，可能会映射到多张表，一张表，也有可能会映射到多个实体，而且表里的字段和实体的属性也不能一一对应。因为，领域实体力求表达领域问题，而数据库的表，更关注于数据的存取便利和性能等。把这两个职责分离后，领域和数据将各自能比较自由的发展。