一个订单系统，使用Hibernate来建模就会包含Order、OrderItem、Product这么几种类型，其中OrderItem包含一个Amount属性和一个Product实例的引用。用户常常提出.

DDD里讲的Repository用于对一个entity的重建，因此Repository依赖于entity是很正常的一个关系。但是在使用中，会遇到entity本身需要访问数据库，如果调用reposito.

在我理解业务对象是一个系统的基础，就像盖房子中的砖头，砖头的形状变了搭建房子的方法也就改变了，同样业务对象的结构改变了，系统的架构和设计也就改变了。所以应该是设计的基础。再来说DTO，字面理解看，da.

《Domain-Driven Design》中对实体有这样的话：对于实体而言，我们关注的重点不是它们的属性或行为，而应该把繁枝茂叶从定义中剔除出去，只留下那些固有的特征，特别是那些用来惟一标识对象，以.

实体域对象的粒度范围问题。如果实体模型跟另外几个实体模型都有不同程度的双向关联（关联是必须的不能删减）那么这个实体模型设计时是否需要把另外几个实体模型关系都包含在自己的属性中那？比如包含两个set 两.

对于"我用电脑写文章"中的实体关系我个人认为只有电脑和文章的关系,而"我"作为参与者,属于系统外部的事物,不必在关系图中画出来,各位是怎么认为的呢?.

快被弄昏了，他们有些什么关系，又应该位于系统的那些层次上面.

ValueObject和DTO模式是常用的J2EE设计模式，模式所体现的不仅仅是一个设计技巧，更主要的是数据封装的思想。最近我在做设计的时候却对这个模式产生了一些疑问。1． 对于位于持久层中的Valu.

（一）对象之间的关系：1． 依赖： 依赖对象通过调用被依赖对象的方法来获得服务。一种比较松散的关系，并且是短期的。我们的过程与对象往往依赖与我们的实体域对象。如在struts 的 act.

我们在开发系统时,一般VO（或者是PO）对应的是数据库中的表中的记录，view object是提供给客户端显示用的对象，在业务逻辑部分是BO。在很多情况下，我们把VO或者是PO作为了BO，但是在复杂的.

模型Model和DTO/VO的区别在EJB应用中，经常会需要传输数据，所以我们需要DTO模式，但是在系统还没有复杂到一定程度时，我们碰到的基本是Model，是Model作为DTO，比如一个数据对象Pr.

message指的是帖子，forum指的是论坛,thread指的是什么的线索？.