DomainModel之控制风格

I know what I know,I'll sing what I said,We come and we go ...
--I Know What I Know,paul simon


   相对于分歧较少的静态DomainModel结构，DomainModel的动态特征一直是扑朔迷离，让人捉摸不定。以至于出现了很多争论，分歧在哪里呢？如果我们把DomainModel整个动态特征看作一个集合，那么，各种争论的分歧就在于“该集合该如何分配到对象上？”。

   在Rebecca Wirfs-Brock的《对象设计》中，提出了OO三种可选的控制风格：集中式、分散式和委托式。

集中式：这是过程式程序遗传的产物。系统中存在两类分工明确的对象，分别模拟结构化编程风格的“算法”和“数据”。在算法对象周围是一群仅仅持有信息的数据对象。聪明的算法对象根据需要向数据对象请求数据，处理得到的数据，向数据对象写入处理结果。应用逻辑的控制权完全由算法对象掌握，算法对象实质上是事必躬亲的控制对象。集中式的一个变种，是多个控制对象共同承担应用逻辑，这等价于功能分解。这种模式的优点在于，通过考察少数聪明的控制对象就可以弄清楚应用逻辑。然而，把动态特征集合，放入少量控制对象，要比放入较多智能对象复杂。另外，结构化编程风格面临的问题依然存在，由于数据对象被多个控制对象使用，处理该数据对象的方法，被分散到很多类中，不同数据对象间持有信息的一致性，通过控制对象间接维护，要做到“单点维护”并不容易。 如果想在数据对象间移动持有信息，将变得困难，因为需要同时维护很多关联的控制对象。

分散式：这是相对集中式的另外一个极端。动态特征集合被均匀的分散到了每一个对象。没有哪个对象比其他的更聪明。应用逻辑严格按照对象间的关联来驱动完成，各对象仅仅同它关联的对象打交道。好比一块由大量齿轮组成的机械表。集中式的优点正是分散式的缺点，要弄清楚应用逻辑，需要跟踪大量对象间的请求/响应。

委托式：介于上述两者之间，动态特征集合被层次化的分配到各对象中。控制者的职责被弱化为协调者，协调者比控制者需要知道的要少。数据对象由于承担了部分动态特征，也“聪明”起来，数据对象也充当起协调自身内部关系的角色。协调者只需要协调其他协调者和聪明起来的数据对象。除了层次上的区别外，他们都可以看作协调者。层次的出现，意味着可以在不同的层次理解应用逻辑，给任务划分提供了合适的界限。对子层次细节的忽略，保证了在系统变化时不会涉及过多对象。当然同集中式相比，需要考察更多不同层次的对象，单个应用逻辑不是非常直观。

我认为DomainModel的控制风格，应采用“委托式”。Model的各部分如同人体的细胞和组织，都略带智能，有明显的分工，协作完成任务。 当然，这里面还有很多问题需要仔细考虑。

大概看懂了一些，不过还是不敢说我明白你的意思。

可不可以简明些：

                             － specification （借用DDD的，描述起来简单点）
domain service  |  
                             － domain object

domain service是个协调者，
各个specification处理了各自的逻辑(validation， selection，building。。)
(rich)domain object处理了属于自己的那部分逻辑

这样？

Domain层的service是个特殊的对象，作为Domain层的外观，承担了同外界打交道的职责。实际上，由于service的特殊性，他们有自己共同父类。它也是Domain层最初和最大的协调者。
要讨论清楚DomainObject间的协作方式，是个大课题，specification是其中的一类对象。此外，还存在party,partyrole,businessinteraction,policy等等对象。

Nod！不过我想补充一下。在我最初的认识中，我也认为Domain Service应该是Domain的最外层，同时我还认为它是面向use case的（我的blog上有，论坛上有几个帖子也有表露），随着认识的深入，我意识到在复杂应用的条件下，应该有一个facade层专门面向use case的，而domain service不应该。所幸的是，在一般复杂度下，这个是不必要的。



party和partyrole作为common的domain，其他domain是应该可以直接访问吧。policy我的理解是可以归入specification一类，businessinteraction不知道在这里是否指与外系统的交互。

我明白你说的含义。不过我们使用的术语同而已。这类对象我叫做“Act”也是
DomainObject的子类，确切的说是"BusinessInteraction"的子类。模拟了短暂的业务活动。

service更像子系统的接口，可以认为它是一个巨大的对象。具体来说是，通过多个service方法可以完成一个UseCase。多个UseCase也可以使用同一个service方法。


party和partyrole确实是DomainModel中底层的包。
policy是比specification复杂的业务规则。
businessinteraction就像上面提到的，描述了所有业务活动的抽象。比如：
agreement，order等等，都是生命周期长度不等的业务交互。

前段时间做了一个项目,我负责财务计算的处理,采用了一个部分负责进行数据的导入,一部分负责数据的存储,一部分负责财务的计算.感觉处理方式上有问题.因为负责计算的部分里面有很多的计算式,以静态方式对外公开.如果按照委托式的方式的话,我是不是需要把某类计算式放到一个单元中呢?如果这样一来类的数量怎么控制,单元间的协作由谁来管理呢?

静观中...............

能具体点么？