模型驱动设计(MDD)之灵活设计

板桥里人 https://www.jdon.com 2006/8/12更新

　　灵活设计可以使我们随着项目开发的进行，感到速度越来越快，而不是越来越慢，甚至停滞不前。灵活设计是对领域建模的补充，当我们从领域中抓住那些隐隐约约的线索和概念原型后，就象准备好原料；下面就是通过迭代将原料锤炼成一定具体的形状，可以俗称“打铁”，那么打铁打到什么形状算可以了呢？也就是最终希望达到什么样的设计呢？

　　有些软件打着“灵活性”旗号，却出现很多多余的抽象和间接层次，从而导致了复杂性，灵活性可能导致复杂性，但是灵活性不是导致复杂性的必然原因，如何将灵活性的发展通往简单，其中精湛技巧就需要学习和不断实践，正确的理论指导是必不可少的，模型驱动设计(MDD)提供这样一个科学的方法论。

　　在Eric Evans的“领域驱动设计”一书中专门探讨了这样提供灵活设计的模式和方法，下面简要述说如下：

明显意图的接口

　　接口的名称必须表达明显意图，而不是模棱两可，接口虽然是抽象，但是也不能抽象到别人不知你所云，如果其他开发人员必须查看接口的实现子类才能搞清楚你这个接口的意图，那么你的接口抽象无疑是失败的，

　　使用明显意图的接口可以将整个子领域切分成一个个单独模块，每个模块使用带有明显意图的接口封装起来，这种切割方式用来调整项目的焦点和对付大型系统的复杂性。

　　如果仅仅有大型系统开发经验，但是没有大型系统的分割经验，更重要的是良好设计理论基础，那些大型系统开发经验也只是如过眼烟云，不会在你的程序生涯中占据多大的重要位置。

　　下面我们聚焦被划分成单个模块的内部设计模式：

边界影响
　　在软件中，操作分为：命令和查询，命令就是能够使系统状态发生改变的操作，如增删改等操作。这些操作都可能需要有副功能，如希望增删改完成后还要返回一些结果，这些主要功能之外的副业，也称为边界影响(side effect)。一些传统过程经验的程序员经常喜欢搞“一机多用”，喜欢将很多功能揉合在一起。

　　大多数操作会调用其他操作，造成任意深度的嵌套，这样形成一个树形结构的调用关系，这就容易使我们很难预测调用一个操作会产生什么样的结果，调用一个操作变得谨慎，甚至战战兢兢，虽然Ioc或DI container使得这种嵌套关系的管理变得容易，但是不能保证每个操作本身的设计能降低复杂性，后者就是我们现在关注的。

　　为什么我们调用一个操作时会变得小心，因为这个操作设计时可能不执行主要功能，还有其他副功能，这些副功能可以认为是一种多余副作用，解决办法很简单：设计这个操作时消灭副作用；如果不能消灭，就将其分离显式分离并单独表达出来。

　　所以，我们设计增删改命令和查询功能时，尽可能分离它们到不同操作中实现，不要在增删改命令执行的同时返回任何领域数据。

　　如果边界影响不能通过设计避免，那么我们就直面它，在增删改等命令执行同时返回数据，当这样做的同时，我们就使用断言assertion来约束我们这样的设计，通过断言能够易于使用单元测试Junit等工具测试。从而保证你的命令简单有规则。

　　总之还是那句有些哲学意义的话：对于边界功能，首先要去除它，如果不能回避它，就承认它，但是同时会约束它。

　　边界影响主要的是Service接口怎么做的问题。在实际项目中，Model和Service是相互结合不断重构的。那么Model和Service粒度是如何界定的？

粒度界定

　　对象的粒度到底是多大？这没有一个统一的规律，哪些属性或行为属于A对象，哪些属于B对象，有时又需要将这些属性和行为分离以便能够灵活组合。我们一般很难确定类的粒度到底是怎样规模表示达到设计目的？

　　首先，粒度不能太大，造成重复和冗余，很多概念混在一起；当然粒度也不能太细，以至于太碎，不能完整表达一个领域概念，例如半个铀原子就不再是铀。

　　类需要尽量准确表达领域概念，大多数领域中都包含某种逻辑上的一致性，而很多程序员有时只注意单纯的设计原则，忽视领域逻辑，设计思考时需要两条腿走路，实现平衡，比如JdonFramework的缓存设计主要应对企业领域大量查询都是在时间上相对集中的查询（如本月度），因为领域中某种逻辑存在(时间上相对集中的查询)，才使得我们决定采取某种设计方案，如果没有这个前提，任何设计方案都是可行的，这也是我们通常讨论的业务场景。

　　每个人对业务领域中很多概念都可能不一致，但不能否认：领域中一定在某个地方存在一种旋律，我们的模型肯定能够与领域某个部分发生共振，问题关键是：我们需要通过不断发现的过程来寻找这种共振，这过程就依赖反复的重构重整refactoring。

　　通过重构，使我们的设计适应我们重新理解了的领域概念和业务需求，概念轮廓(Conceptual Contour)就会浮现。

　　注意“概念轮廓”是指对领域中概念的主要轮廓，大概样子，需要忽视不重要的细节，设计人员必须理解领域中概念在哪些地方会发生改变？哪些地方保持相对稳定，然后使设计的模型尽量与领域中概念稳定面结合起来，这样，当业务领域中概念发生变化时，我们的模型才会随之一起翩翩起舞，发生共振，从而达到模型设计反应领域本质的目的。

　　所以，类的粒度是要能够反应领域的概念轮廓，将能够反应概念轮廓的那些重要元素聚合到当前正在设计的类中，这也是设计中高聚合原则的体现。

　　高聚合、低关联是两个设计基本原则，上面我们谈了如何做到高聚合，实际上，也是反映一种类或模块的粒度设计规模。下面谈谈低关联：

消灭依赖

　　复杂的依赖关系无疑提高了系统的复杂性，加剧我们大脑负载，所以，我们的模型之间关系必须精练，减少依赖，最后保留下来的依赖代表了领域概念之间某种根本的关系。有的系统中，甚至是0关联，从而得到一个个被完全孤立的单独的类(standalone Class)，这才是方向（也有利于我们简化配置Hibernate这些模型持久化框架，无需考虑一对多等关联配置）。

　　每个依赖都是值得怀疑的，这是我们思考的前提，重构时，一个个去消灭那些象蜘蛛网一样密集的关系，斩断它们，低关联时减轻概念过载问题的基本方法，孤立类是低关联达到极致的一种标志。

　　减少依赖不是意味不考虑业务领域场景概念，武断实现，依赖和之前描述的边界影响一样，有时确实不能消灭，那么我们就承认它，但是会又有一套设计原则来约束它。