Rich Domain Model In Java ORM

一直有一个疑问，持久化逻辑转移到domain object后，难道不会产生large class，对代码的维护和修改造成影响？

在项目中实际上会存在一些职责特别重的类(表)，整个业务链都是以它们为起点开始驱动俄。service分层可以分担它们的职责，而domain model如何解决这个问题？

很久以来，我一直反对Domain Model解决一切Logic问题。一个典型的业务场景是一个顺序的Process，这个Process对外表现就是Service Logic的接口。任何一个Process可以很简单，也可以很复杂，简单的Process或许只需要改变某个Domain Object的状态就行了，复杂的Process需要肢解成许多小的Process，并将他们组合起来完成整个逻辑，这个肢解的过程是递归的。这样一个过程是无法直接用Domain Logic来完成而需要一种“外力”来定义，那就是Service Logic.

...
if("delete".equals(request.getParameter("action")))
{
   long id = Long.parseLong(request.getParameter("id"));
   tob.get(id).die();
}
...

public class Worker extends TheObject
{
...
  @Override
  protected void killingNotify() throws ObjectDependedException
  {
    if(this.tasks.size() > 0)
      throw new ObjectDependedException("This worker still has work assignment!");
  }
...
}

要么全盘entity话。事务边界在外面基础设施作，比如filter,intercepter 或者action。

要么 servce 和 rich domain model并存。

我选择先一步步走的方式。

先 service 和 entity并存。 service充当事务和逻辑的组合者。

entity上增加了CRUD的功能，可以使得原本 “贫血模型“中的显得“臃肿“的Service的代码分离很多出去到 Entity中，但是这个分离 我觉得应该有几个指导原则，不然就有点混乱了，有几个指导原则可以给大家作为参考：

*  entity 尽量不需要依赖外围Service组件

* 因为Entity增加了Query,Update的功能，那么原来很多只能在Service上作的代码可以相应作为Entity的领域逻辑 而 移入到 Entity的领域方法中 ，使得 Service的代码大大减少，整个功能的逻辑很好的分离到Service 和entity层中。 


* 属于Entity的逻辑代码 应该 有这么几个特征：
               #  依赖于本身的或者别的实体的状态
               #   依赖于本身的或者别的实体的查找结果 (Query)
               #  修改实体的状态 （包括数据库的状态）

#  如果一个复杂功能需要几个外部组件的完成，Service 负责这些外部组件的调用。

依赖于本身的或者别的实体的状态

rich domain model的目的是什么?
我想最主要还是为了稳定,能灵活的应对各种变化吧.
1.那么业务是多变的,所以domain model不要含有业务逻辑.但是domain model又恰恰是为了解决业务问题,没有业务问题,也不会有domain model,所以rich domain model要面对的是提取或是抽象出让它对付的业务问题.


我把firebody说的实体的状态理解成为我说的抽象出让它对付的业务问题

2.rich domain model依赖于数据库,orm吗?我想为了rich的目的,让它去吧,没什么了不起.至少不会比依赖于业务的细节严重

3.如果按照TDD的经典做法,抽象出业务问题的过程,应该是先把业务逻辑写到domain model去,然后臭味->重构,臭味->重构....直到臭味很少很少

这个从系统整体架构分析, 得出的结论是一致的. Domain Model是用来封装系统内部状态, 再现问题实质的.

另外对于Service, 宽泛的讲, 本质上任何用户界面和公开API都可以认为是系统对外提供的一种Service. 一个JSP页面也可以认为是一个Service, 它照样有 输入(Form Fields), 有 处理逻辑(Scriptlet), 也有 输出(结果页面).

用个代码的例子来说明, 比如响应用户操作, 删除一个Worker对象:

...
if("delete".equals(request.getParameter("action")))
{
   long id = Long.parseLong(request.getParameter("id"));
   tob.get(id).die();
}
...

以上就是Service Logic.

而要检查被删除的Worker如果还有被分配的任务就不能删除的逻辑, 应该作为Domain Object的行为来实现:

public class Worker extends TheObject
{
...
  @Override
  protected void killingNotify() throws ObjectDependedException
  {
    if(this.tasks.size() > 0)
      throw new ObjectDependedException("This worker still has work assignment!");
  }
...
}

以上就是Domain Logic, 不应放在Service里实现.

没有人说要让“Entity绝对不能依赖Service组件”吧，
ORM能处理大部分的普通需求，再甚保留对native sql的支持不是已经满足你的要求了，你说的查询引擎要作到什么样的效果呢，能否具体点，
目前的很多通用查询工具难道都不能满足吗，不存在所谓的平面问题吧，
就看你自己怎么想了，三维地图也是显示在你的平面显示器上的哦，
查询方面的OO本来就是为了复用吧，有复用就可以看做有引擎了哦，呵呵

Entity绝对不能依赖Service组件是我的观点，因为我认为Service组件存在的意义就是定义各种Process来规划各种Entity状态的维护顺序。如果Entity对Service组件形成了依赖，那么必然造成双向依赖，这个是我无法接受的。

另外对于查询来说，我想你还没有明白我的意思，我不是说ORM做的不好。而是我在想这样一个问题，为什么对于数据库的查询要经过ORM这样一个过程？无论是hibernate的hql或者native sql，他们作为引擎时，都会将查询的结果映射成Java世界中的对象，即使是iBatis这样的SQL Map工具，也一样无法摆脱这一俗套。

我承认，在解决了lazy load的问题之后，orm的查询方式更加具备扩展性。但是事实上呢？这种扩展性是以效率为代价而产生的。回想数据在数据库中的表现形式和在页面或者报表中的表现形式，他们是极其一致的，为什么不考虑类似微软的dataTable的方式来解决这个问题呢？绕过所有的对象映射，恢复这些数据的本来面目。

这里讨论的就是实现的问题，由于框架和语言本身的特点，导致实现上难易程度不一致，因而需要设计不同的RichDomainModel。
至于你说的根本问题那是另一个话题。

rich domain model的目的是什么?
我想最主要还是为了稳定,能灵活的应对各种变化吧.
1.那么业务是多变的,所以domain model不要含有业务逻辑.但是domain model又恰恰是为了解决业务问题,没有业务问题,也不会有domain model,所以rich domain model要面对的是提取或是抽象出让它对付的业务问题.


我把firebody说的实体的状态理解成为我说的抽象出让它对付的业务问题

2.rich domain model依赖于数据库,orm吗?我想为了rich的目的,让它去吧,没什么了不起.至少不会比依赖于业务的细节严重

3.如果按照TDD的经典做法,抽象出业务问题的过程,应该是先把业务逻辑写到domain model去,然后臭味->重构,臭味->重构....直到臭味很少很少