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

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

　　明显意图的接口

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

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

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

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

　　边界影响

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

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

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

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

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

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

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