DDD实体模型

各位在进行领域驱动设计开发的时候，实体的“合法”性是如何实现的，怎么保证实体的一致合法性？检验代码分布在实体中，还是在服务中，还是都有？如果分布在实体中，如何保证一次性校验，使用构造函数或工厂保证？如何得到校验上下文？有种说法是实体永远有效；另一种则相反，必须经过业务逻辑校验才能算是“合法”实体。大

大家好，又是一年春草绿啊，祝大家步步步高升，少摸电脑多触人。我现在还是不能理解，DDD中的实体和数据库中的实体，有什么区别和联系，我的感觉，DDD的实体去掉其中的方法，留下的就是数据库的中的实体，不知道，我这个理解对不对呢，如果是这样，那我反过又有什么不可以呢，先花ER图，再为实体添加方法，

不知道大家有没有这样的疑惑，在项目中使用DDD时，领域对象有时候需要调用BO，BO有时候为了实现特殊的数据库操作，又需要跨过Repository直接操作领域对象。 本来负责逻辑运算的BO是不应该和领域对象打交道的，比如将人民币转换成美元，个人感觉是应该放在

按照DDD的思想， 实体是不应直接暴露set/get方法，而应该是暴露有实际含义的操作。但是实体之间以及实体与DTO难免存在拷贝的问题，一般会采用一些拷贝的工具类来实现，那么这里问题就出现了，如果实体不暴露set/get方法，那么拷贝的工具类是无法执行的。另外，对于hibernate这种OR

领域开发真的是经验学，只有再使用中才能成长。我想问下，有这样一个需求，系统需要让用户可以通过存在的积分兑换现金（假设是现金）。有两种情况，一种是用户填写银行卡和电话信息，通过电子转账返还给用户一种是用户填写邮寄地址和电话信息，通过邮寄支票返还给用户

  DDD中强调“领域对象是拥有行为的”。这句话我觉得说法是正确的，但是其做法难道就是“在领域对象里写方法”这么简单吗？   我们常说“类应该具有生命的”，但我不认为“把方法写到类里就会让类具有生命了”，因为"把简单地把方法写到类里，

对DDD不熟，看过JDON上的一些帖子后，主要有以下两个疑问，希望大牛不吝赐教 1.如果使用hibernate的话，那么领域对象是不是应该和hibernate的持久对象是同一个对象，只是这个对象现在多了职责这个东西，也就是充血了。

DDD的实体类确实应该驻守在内存中，但实际上我们会发现内存相对还是昂贵的，那么我们可以让实体类的一张皮放在内存中，而大的字段可以懒加载。 我用javascript 代码做一个说明。

初学DDD，对一些基本问题不清楚对于实体合法性校验，校验方法是在实体里实现。但是在何处调用呢？是由服务层业务逻辑主动调用还是由持久层主动调用？或者通过事件触发进行被动调用（如在实体的setter方法里触发事件或是其他可能的地方触发）

各位好，小弟对DDD非常感兴趣，可是没有实际的使用过，看了论坛里的帖子，还是有点迷糊，所以想请教各位。我现在要做一个用户注册的系统，而用户注册分两类，一类是通过手机号码注册，一种是通过邮箱注册。我按照四色原型来建模，模型如下。不知道对不对，请各位赐教！小弟不胜感激。

在看论坛，发现不怎么明白实体和一般值对象的区别，什么是实体？ 在我们开发的项目中，我们在DAO层采用的对象是BO，然后在传输层，我们把BO-->DTO,最后在显示层，我们把DTO-->VO,页面采用VO来进行开发，我觉得这样转换效率很低，但是从分层的角度来看，每层有每层想表达但是不

最近一直在看领域驱动设计的书，感受到了理念，但是一些细节方面不知道自己是不是理解对了。请大家指教。 聚合根的内部实体之间的相互可以引用。聚合根A内部有B，C，D。那么，B，C，D之间都是可以相互引用的，但是他们可以引用A么？？？

比如一个系统中 A B C 三个entity.A 可以独立生存，B需要有A才能生存，C需要B能生存，那么这种 Aggregate如何划分？

很多企业级的应用还是基于数据库的事务性操作，至少我遇到的是这样的。一般在一次业务操作开始时候，会建立很多业务对象，之后开始具体的业务操作，操作完成后，数据会被及时更新到数据中，之后这些业务对象被清理掉。这样，我们建立业务对象往往不会存在“状态”（内存中）这样的概念，只是作为一个数据的临时包装

最近在看些关于设计模式的东西，其中看了将PO,BO,VO这三个解耦合的知识，有点不明白。把这三个分开设计，真的能做到解耦合？修改其中一种不影响其他的？其中相互转换会不会消耗性能？请高手为我解惑。。。我一直以来都只写PO，原因是VO我用JSONObject代替了。反正刚开始感觉

前提是，对象都在内存中。 那么当我们验证也是业务的一部分，那么比如修改A对象。