DDD之领域模型（续）（烧脑）

(笔者wo在川知乐 简称老乐）

DDD（领域驱动设计）是目前主流的软件设计思路和方法，特别是微服务大行其道以来，DDD更是作为微服务的拆分手段被推广开来。和其他设计思路比，其具备整个系统的全局视角，从需求出发，梳理出典型用户场景，实现业务逻辑、系统逻辑和部署逻辑的分析设计，打通问题域和解决方案域的壁垒，提供一揽子解决方案，使得领域模型成为系统演进的核心，从而消除设计和实现之间的mapping，进而获得易于理解、分层清晰、易于维护的软件系统。了解任何一项新技术，对概念的了解都十分重要，它们贯彻整个体系；本文就DDD中的重要概念做一些思考和阐述。

上一篇文章重点讲了从领域（问题域）中建立模型的过程，见上图的左半部分，具体思路是对领域进行抽象和组织，采用离散化->符号化->结构化的递进方式，从而对领域进行解耦和拟合，进而得到清晰表达的领域模型（以下简称DM）；本文重点讲讲上图的右半部分，DM和实现的相互塑性。

DM和实现的相互塑性分为这几部分：映射、编排和降解。

1、首先看映射，映射其实就是DM在实现域的表达。一般来说，DM可以通过DSL（领域专用语言，又分为内DSL（宿主语言）和外DSL（自然语言））来表达；也可以使用XML/YML/JSON等结构化的形式表达；或者就是定义一套可组合的API；甚至是一套Data Type。后面这些都可以看做是DSL的一种变种或简化，说白了，都是为了使DM的表达具有的原子性、组合性和抽象性，即组合后的东东还可以和别的原子或组合进行再组合。2、编排是指领域实现层通过编排调度DM表达层的元素，实现上层业务流程和业务逻辑，这层侧重于对领域模型的应用；同时顺带验证DM的正确性和完整性，反过来塑性DM和与之对应的表达元素。3、重点看降解，这一层的含义是如何把DM的表达层的元素通过通用编程语言进行实现，这种实现一般表现为语义（Semantic）降解的过程，所谓降解，就是一个分解、下沉、细节化的逐步过程，比如我们看到c语言的if语句，马上就会联系到汇编语言的mov、test、jump等语句，这就是两个不同level的DM间semantic平滑下降的过程，这其实就是个语义降解的过程，好的降解的一个重要特征就是平滑。

降解的方式一般分为两种，操作语义的降解和指示语义的降解。

什么是操作语义的降解呢？就是把DM表达层的概念，一步步分解开来，分解一步，就运算和估值这部分。比如我们教一个没有中文基础的老美学汉字“走”，老美可能摸不到门道，但是如果我们把“走”过程拆解出来给这个老美演示，比如走就是先摔胳膊，然后迈另一侧的腿，同时身体向前移动。

这个老美看了这些动作组合后，恍然大悟，这就是中文“走”的意思。这种一步步做给你看的方式非常直观和自然。其本质就是并列拆解或第次拆解，然后进行早估值（early evaluation）。

那指示语义呢，就像进行一个翻译，比如还是那个老美，教他中文“走”，直接告诉他“walk”，老美马上点点头，I see，I see。这个就是指示语义。

本质也是并列拆解或第次拆解，只不过拆解后不进行运算和估值，而是转换成另一门编程语言（一般为通用编程语言，比如c/c++、java、python等）的执行序列（指令集合，类似虚拟机的字节码）+自定义指令集（用通用语言表达），最后真正运行时，在自定义指令集上执行这套序列，整个过程分为生成执行序列+执行序列，可以一次生成，多次执行。属于晚估值（lazy evaluation）的范畴。

前一种非常类似于通用编程语言的解释器，后一种自然就是类似于编译器+虚拟机了。

前一种语义降解地非常直接自然，但是语义降解过快，细节较多，容易丧失可理解性（老乐在DDD长期编程实践和对映射、编排、降解落地培训中深刻认识到：系统的可理解性是衡量软件好坏的一个非常重要的指标。首先只有可理解才能知道实现的对或不对，切记，千万不能仅因为测试后正确而认为软件就正确，正确的次序一定是可理解放在前面，理解软件后发现其正确，然后再测试验证其正确，这才是真正的正确；其次，可理解的软件才能进行维护和演进），且和领域层耦合较多，适合小规模系统；

后一种相对复杂，但语义降解比较平滑（可理解性的一个重要障碍就是语义参差不齐，上下跳跃），易于理解，而来利于提前优化和性能调优，这也是晚估值的优势，并且架构分层比较彻底（编译器和指令集与领域层泾渭分明），对团队的分层也比较有好处，适合大规模系统。

综上，领域模型启动承上启下的作用，对领域进行抽象和组织，和实现直接通过映射、编排、降解来互相塑形。其中，降解是为了语义的平滑降解，就像正常客机降落时盘旋逐步降低高度，平稳着落。而不是一个像失事飞机一样，一个猛子扎到低，造成可理解性严重下降。

可理解性是我们软件设计追求的重要指标之一，大家务必重视。

至此，DDD中领域模型终于讲清楚了。