domain model浅析

《domain model浅析》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、在深入讨论之前我先抛出一些原则和概念，最后你会看到这些概念和原则的威力。1.按照概念依赖的原则来组织业务层。2.将业务活动（业务流程）建模成类。3.用业务活动（业务流程）作为关联整个业务层各种对象的骨架。4.在业务活动中凿出扩展点，使用不同接口分离不同性质业务对象。5.将对象的存储理解为业务层概念。......概念依赖这是我认为能否得到良好业务层最重要的概念。在我系统框架设计将要完成，开始涉及业务层设计时，我脑袋一片空白，书上，大家讨论的大多是整个系统的结构从UI层到服务层到数据访问层到数据库。到底业务层该如何组织？MartinFowler的POEAA的书中没有回答。找到的

2、相关书籍也都过于空泛。MartinFowler的分析模式有些用处，但不够系统。透过Martinfowler网站，我拿到了DomainDrivenDesign的发行前版本。该书给了我很大的启示。其中的要点有：关于关联：1.Imposingatraversaldirection(强制一个关联的导航方向)......关于ResponsibilityLayers（业务职责层）的划分：作者给出了三个指导原则：Conceptualdependency.(概念依赖)为其中一项。书中给出的描述的是业务职责层上层的对象需要通过下层对象才能在概念上完整，相反下层对象则可独立于上层对象存在含义。

3、这样天然的下层对象相对于上层对象会更稳定。并且在今后演变的过程中，使同扩展的方式来完善系统，而不是改变对象的方式。通过实践，我觉得这条原则可以应用在任何两个有关联的业务对象上。通常可以通过概念依赖先建立一个导航方向。这能够满足大多数的需求。当确实需要反向导航时，只要理由充分可以随时加上，并且如果先前将这两个对象放入不同包中，这时需要将他们合并到同一个包中。我见过一个不好的设计。Customer具有很多Flag分别标记该客户是否挂失，冻结，注销等等。通常叫做客户状态,然而这是不对的，这违背了单一职责原则。事实上除了注销外挂失和冻结都不应该算作Customer的本质属性。相反我

4、把他们看作某种约束，进而把挂失看作一种协议.....因为Customer的概念可以不依赖于挂失和冻结的概念，相反挂失和冻结却要依赖Customer的概念，应为这是他们动作的主体。同样的一开始就让Customer有GetAccount的方法同样不好。因为Customer的概念确实不依赖AccountXXXAccount却可以有Customer的属性，Account在概念上依赖Customer。按照概念依赖原则我们能更好的理解业务职责层的划分。DDD中建议了如下的职责层。按从高到低分别为：依赖方向

5、Decision

6、Policy

7、Commitment

8、OperationVPot

9、entialPotential中包括类似Customer,Employee等Party方面的类。对应支持业务。Operation中包括了核心业务如存取款，买卖以及同这些业务关联的Account，Product等等。Commmitment对于客户包括同客户签订的协议等。对于员工来说包括授权等。Policy包括计算某种收费的策略，比如电信收费的算法。对应支持业务。Decision包括主要对应于管理业务。监控系统多在这层。从上到下观察，很好的遵循了概念依赖的原则。从另一方面来看，可以根据概念随着时间发展的顺序来建立对象之间的关系。这样会天然的满足概念依赖原则。后面发展起来的概念可

10、以依赖前面的已经存在的概念，而反过来这不可。这是系统稳定的关键。同客户签订的各种协议可以不断的发展，但是客户对象是稳定的。同理收费的策略可以变化但是最终反映到帐户上的都只是对Balance的变更。所以收费策略比帐户更不稳定。客户对象也要比帐户对象稳定。从按照稳定的方向依赖的原则出发，我们可以得到对象间的单向依赖。当然也会存在双向关联的对象，然而这种情况在我的实践中不是很多。而且一旦你懂得了单向关联的好处后，你就会谨慎的使用双向关联。滥用关联会使得整个业务层象DDD中说的，变成一大块“果冻”，你随便触动果冻某一块，整个果冻都会颤动。同样为了简化设计，对象的关系中多对多的关系尽

11、量避免。如果可以则通过限定角色转化为一对多或一对一的关系。以上是关于概念依赖的观念，下面让我们看看如何建模业务中的活动。有一种做法是使用分析模型中的控制类直接映射到设计中类中。我看来这不是好的做法。这里谈谈分析与设计的区别。从分析的角度来看，业务实体总是被动的。业务是通过控制对象操作业务实体来完成的。分析时我们是关注是什么问题。这要求我们客观的来描述现实。进入设计阶段我们关注的是如何解决的问题。控制对象施加与业务实体的操作加入不涉及第三者，则这个操作可以并入被操作的实体类中。然而分析中控制对象的概念是如此的深刻，以