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

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

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

明显意图的接口

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

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

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

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

边界影响

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

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

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

所以，我们设计增删改命令和查询功能时，尽可能分离它们到不同操作中实现，不要在