柔性设计是对深层建模的补充。

早起的设计版本通常达不到柔性设计设计的要求。

可以通过以下几个模式帮助实现柔性设计：

1.intention-revealing interfaces

问题：如果开发人员为了使用一个组件而必须要去研究它的实现，那么就失去了封装的价值。

解决：因此，在命名类和操作时，要描述它们的效果和目的，而不要表露他们是通过何种方式达到目的的。这样可以使客户开发人员不必去理解内部细节。在创建一个行为之前先为它编写一个测试，这样可以促使你站在客户开发人员的角度上来思考它。

2.side-effect-free-function

问题：多个规则的相互作用或计算的组合所产生的结果是很难预测的。开发人员在调用一个操作时，为了预测操作的结果，必须理解它的实现以及它所调用的其他方法的实现。如果开发人员不得不这么做，那么接口的抽象作用就受到了限制。

解决：尽可能把程序的逻辑放到函数中，因为函数是只返回结果而不产生明显副作用的操作。严格地把命令隔离到不返回领域信息，非常简单的操作中。当发现一个非常适合承担复杂逻辑指责的概念时，就可以把这个复杂逻辑移到value object中，这样可以进一步控制副作用。

3.assertion

4.conceptual contour（不理解）

问题：如果把模型或设计的所有元素都放在一个整体的大结构中，那么他们的功能就会发生重复。外部接口无法给出客户可能关心的全部信息，由于不同的概念被混合在一起，他们的意义变得很难理解。另一方面，把类和方法非解开也可能是毫无意义的，这会使客户更复杂，迫使客户对象去理解各个细微部分是如何组合在一起的。更糟糕的是，有的概念可能会完全丢失。

5.standalone class

即使是在module内部，设计也会随着依赖关系的增加而变得越来越难以理解。这加重了我们思考负担，从而限制了开发人员处理的设计复杂度。隐式概念比现实饮用增加的负担更大。

解决：低耦合是对象设计的一个基本要素。尽一切可能保持低耦合，把所有的无关概念提取到对象之外。当一个类与它所载的模块中的其他类存在依赖关系时，比它与模块外部的类有依赖关系要好得多。低耦合是减少概念过载的最基本方法，独立的类是低耦合的极致。

6.closure of operation

在适当的情况下，在定义操作时，让它的返回类型与其参数的类型相同

声明式设计