《领域驱动设计》读书笔记（7）——柔性设计

释意接口

就是让软件的接口包括类名，方法名，参数名等，能表达出这个接口的意图，达到的效果。 如果开发人员必须考虑组件的实现才能使用它，那么封装就失去了价值了。如果某个人（除了组件的原作者）必须根据实现来推测一个对象或操作的意图，那么他推测出来的很可能只是那个对象或操作的偶然完成的。如果他猜错了意图，那么代码可能会在一段时间内正常工作，但是设计的概念基础已经被破坏了，两个开发人员的工作变得有些驴唇不对马嘴。 类和操作的名称应该表达出其效果和目的，同时又不涉及它们为了达到承诺而使用的手段，这样才能避免客户开发人员需要去理解内部实现。名字必须与通用语言一致，这样小组成员才能迅速理解它们的含义。在创建类和操作之前先编写测试代码，这样能促使您从客户开发人员的角度来考虑问题。

无副作用函数

一个函数如果在执行过程中不会改变除临时变量之外其它对象的状态，就可以把这个函数看成无副作用函数。无副作函数可以让使用者放心的使用，不用担心调用之后会引起怎样的不可预知的效果。 多条规则的相互作用或计算的组合将使预测变得极度困难。为了预测调用一个操作的结果，开发人员必须理解操作本身，及操作调用的所有其他操作的实现。如果开发人员被迫去理解那些内部实现，任何接口抽象都不会有多大用处了。如果不能安全的对抽象结果进行预测，开发人员就必须限制“组合爆炸”，从而为系统行为所能够达到的复杂性人为地设置了一个上限。 尽可能的将程序逻辑放到函数中，以及只返回结果而不产生可观测副作用操作中。将命令（导致可观测状态产生改变的方法）严格地分离为非常简单的、不返回任何领域信息的操作。如果概念与职责明显匹配的话，我们还可以将复杂逻辑移入值对象，以进一步减少副作用。

断言

断言，其实就是用程序来声明程序在运行过程中应当满足的约束条件。如果语言支持，可以在开发过程中就给函数加上断言，以声明函数的前置条件和后置条件，既可以帮助我们找到故障发生点，又可以帮助代码阅读者理解设计意图。单元测试也是断言的一种方式，可以显式地说明程序单元执行后的效果。

概念轮廓

领域对外提供的接口，如果粒度太细，则客户端必须了解领域细节才会使用，而且会导致客户端的代码重复，如果粒度太粗，则对于客户端来说领域不灵活，领域层也可能出现太多功能在一个对象之上。因此要通过重构，寻找最合适的粒度来表达领域。要足够细，细到能贴合领域的稳定面，要足够粗，粗到客户端能方便使用，能了解领域的含义。 比如，假如“添加两个对象”在领域中，就是一个完整的操作，那么对应的模型中就不应该把添加两个对象分步来表达。

孤立类

即使是在模型块内部，设计的理解难度也会随着依赖的加入而急剧上升。这会进一步加重大脑过载问题，进而限制设计人员能够处理的复杂度。如果存在隐含概念，那么它造成的大脑负荷比显式的引用还要大。 低关联是对象设计的基本原则，只要有可能就应该这样做。从图中把所有其它概念全部排除出去，只剩下一个完全自包含的类，这样我们就能单独观察和理解它了。每个这种自包含的类都明显地降低了理解一个模块的难度。

操作封闭

正如对整数的加减运算只会产生整数一样，如果模型中操作的返回值和参数是同一种类型的话，就可以不引入新的概念而描述这个操作。 在适当情况下，把操作的返回值与其变元定义成相同的类型。如果在计算中要用到实现者的状态，那么实现者实际上就是操作的一个变元，即操作的变元和返回值应该与实现者是同一种类型。这样的操作对于这种类型的实例集合就是封闭的。封闭的操作为我们提供了一个高层接口，同时又无需引入任何对其它概念的依赖。

声明性设计

这个就是说努力提炼自己的DSL了。

转载于:https://my.oschina.net/komodo/blog/919178