再论domain model

现在总是对domain model似懂非懂，domain model应该包括两部分吧，domain object和domain logic，而domain model强调是在domain object中添加业务逻辑，这些业务逻辑是可复用的，通用的，而不是真对某个特定的实体而有的业务逻辑，现在有好几个问题：
1、domain logic中应该写些什么呢？特定的业务逻辑？使用策略模式的业务逻辑？
2、使用domain model后，应该如何分层呢？service层又该承担一些什么东东呢？facade？业务逻辑facade？还是存取逻辑facade？

1.domain logic里应该完成某一个和该domain object相关的业务逻辑，或者说可以被认为是该domain object的一种行为的业务逻辑。这种业务逻辑可以是一个策略算法，也可以是创建其他domain object并调用他们的行为方法。
2. 使用了domain model后,由于domain object本身也是业务数据的封装，因此需要orm层来将其持久化。如果需要远程调用，则可能需要facade，应该算是业务逻辑的facade。此外service层还有可能提供事务处理等等机制。

spring1.1带得jpetstore 得domain模型值得新人去看 logic里包括了一些domain本身的validator和petstorefacade和petstoreImp等，service里只有一个rmi订单服务

spring1.1带的jpetstore，其实我认为这也是domain model，但是曾经在gigix的blog上看到，jpetstore仍是采用的transaction script，其实我也有点不解，或者如gigix对G-roller的评价：东西太简单了，ts和domain model并没有本质的区别。

PAEE中讲到的DomainModel，是DomainObject+DomainLogic。DomainLogic就是纯粹的业务逻辑。

不过表现出的形式有些不同，可以是纯粹的POJO＋业务逻辑的Service，也可以是含有业务逻辑（DomainLogic）的一个完整的DomainObject。

是否用策略模式实现，要看具体的需要了。

个人认为，如果业务相对简单的话，将逻辑写在DomainObject内，会更加的方便，不需要特别的Service或Facade。

我觉得domain model最重要的一点应该是 业务逻辑的复用，所以非通用的业务逻辑不应该写在domain object里，今天又看了一下jpetstore ,我觉得也是使用了domain model模式，不明白为何gigix说jpetstore仍是采用transaction script模式。

至于service里面，不应该含有业务逻辑，那么至于service中应该包含什么，看了jpetstore后，觉得应该是Sayor所说的业务逻辑facade，既然是facade自然有facade模式的好处，service层有存在的必要，不能省略