关于实体域对象

>是否应该只要有关联就包含他
是的，这是关联的Java表示法。

>关联是必须的不能删减
这个不是完全正确的，高聚合 低关联是设计原则，只要能够区分出关联和聚合的微妙区别，我们就可以留下聚合，剔除关联，Evans DDD认为不必要关联就不要，双向关联必须杜绝，有人曾经搞了一个大系统几百个光头模型，这说明，关联只要分析到位，可以去除的。

banq:有没有实际的例子说明？我现在也遇到类似的问题，不知如何解决

>有没有实际的例子说明
jivejdon3.0就是实例阿。

现在对持久层有些迷惑，觉得可能是有很多种设计方法，不是很绝对的就得怎么去设计。hibernate的设计就是针对对象关系映射，他的实体设计方式似乎和我们最早使用的jdbc直接CRUD时的实体设计方式不太一样。（我只是觉得不知道对否）。Hibernate可以把对象间的关系分析的很透彻。用几种策略表达对象间的关系。可通过这种关系将对象持久化。而jdbc则不同，可能会多写些循环，多几次调用。关系是我们自己在对象间维护的而没有那些像Hibernate的策略，这样就给人设计上的迷茫感，好象有一个应该是对的，或者说好象Hibernate是标准的，但又不能把他的策略应用到jdbc中。这可是banq最重视的实体域对象啊，弄不好系统就不怎么好。很关键值得学习

需要搞清楚Hibernate在软件开发中位置！

首先通过Evans DDD设计出实体对象，以及他们之间的关联关系；然后使用Hibernate进行编程实现这些实体对象和他们关联关系的持久化。

借鉴Hibernate这些o/R mapping做法，我们使用JDBC也可以实现，而且实现效率肯定比Hibernate高。

例如：Hibernate为了提供1:N的性能（减少其内部JDBC执行次数），它建议1:N要双向关联，而Evans DDD设计原则是少用双向关联，这就矛盾了，是服从HIbernate还是Evans DDD?当然是DDD，但是性能不能照顾，所以，使用Hibernate后，必须使用双向关联配置。

而使用JDBC，则就可以做到纯净地服从Evans DDD的对象设计原则，而不必因为技术性能原因，曲改设计原则，这就是Evans最近谈话中强调：需要让开发人员专心业务设计，而实际现在很多技术平台如Java，因为考虑性能原因，经常需要在设计和性能之间做平衡，这是当前技术发展水平的局限。