DDD（2）-从领域驱动到模型驱动

前言

上一篇文章：领域驱动设计整体理解谈了一点我对领域驱动设计这个新的软件设计方法被提出背景，概括地说，领域驱动设计提倡将软件设计的重心放在对业务的建模描述，而非技术实现。本章继续探讨为什么要这么做，如何做。

系统为何会失控

软件是对现实世界的映射，业务最终要落地成代码来描述，这称之为业务建模。如果业务建模和客观的业务事实越接近，显然软件的可维护会越高。但为什么大多数复杂系统最终都难逃腐化、复杂度失控，最终走向推到重来的命运呢？业务受现实世界的客观约束，其代表着公司如何运营，资金如何流转，其变化空间是有限的，变化速率是有限的。而软件仅仅是一行行代码字符串，增删改查也只不过是硬盘中几个文本文件的变化，成本低廉，约束极少，照理说，软件的变化速率是绝对能跟上业务变化的。当我们说系统不可控时，意味着我们没法再改造它以添加新的功能，也就是说软件的变化速率已经跟不上业务的变化速率了。为什么会这样？我认为根本原因在于持续上升的软件和业务间的不一致性。
很多人都听过一句调侃产品经理和程序员的话：这个功能很简单，怎么实现我不管，明天上线。这句话说明了一个问题：软件系统对于产品经理或者业务人员来说，是一个黑盒。他们只知道系统上线之后，通过在系统上点点点就得到自己想要的数据了，他们不知道也不关心软件内部是怎么实现。而他们对齐的标准就是系统上线后表现出来的行为。虽然系统在功能上和业务预期一致，但内部的实现是由开发人员根据对业务的理解、抽象，再夹着着技术实现一起融合、排列、组织得到的。由于没有有效的对齐的工具、流程，这个“内部实现”和业务实际的流程、脉络已经存在不一致，毕竟“怎么实现我不管”。当业务按照现实规律路径进行演化，需要系统增加功能时，开发人员按照自己对需求的理解，按照软件的演进规律增写代码，向需求目标前进，两者的不一致性继续增加。只要软件能持续的达成需求目标，就不会有人来关心两者不一致的问题，直到两者的不一致，已经不再能支撑软件继续满足业务要求，迎来重构。

DDD如何解决不一致性

DDD解决这种不一致性是基于软件开发的全流程的。从需求沟通阶段开始，其提出工作链路上的所有人员都需要统一语言，开发人员应该和业务专家使用统一的术语、名称，通过建模的方式来描述业务流程。把原来只存在于各自大脑中的概念、理解，转化为看得见的模型、流程图、命令、事件，通过白板、文档等方式展现，在软件开发阶段，要求软件中的代码和产出的模型保持一致。
这样做的好处是显而易见的，经过充分讨论后产出的模型，符合业务事实，那么其必然能和业务变化速率保持一致。软件中的业务代码（和技术实现隔离）和模型一致，也必然能和模型变化速率保持一致。技术实现对业务模型是强依赖，必然要和模型保持一致，最终的结果，就是软件系统不仅外表（功能表现）符合业务预期，其“内部实现”也和业务一致，也因此保证了软件能长期、持续的跟随业务变化的可能。只要链路上的各方人员都遵守这种讨论-建模-业务代码描述-技术实现工作流程，软件系统的生命力将会大大提高，而且各方对软件的现状、将要变更的方向、预期、成本都有一致的判断，不会出现产品经理觉得“功能很简单”但程序员却说“这个做不了”的相互矛盾的认知。

上一篇：领域驱动设计整体理解中我们认为领域驱动设计其实是业务驱动设计，结合上面的讨论，我们可以再深推下，认为：领域驱动设计 = 业务驱动设计 = 模型驱动设计，那么自然得出领域驱动设计最重要的环节，就是设计一套各方都能理解的模型，用来描述业务和指导开发。

总结

本篇从探讨系统为何失控出发，得出根本原因在于持续上升的系统内在实现和实际业务脉络的不一致，而DDD提出通过统一语言、全流程、全角色、统一建模的方式来描述业务，提供一个“公共黑板”将各参与方的心智统一到业务实际上，并通过业务代码和模型保持统一的要求，使得软件系统的内在和业务实际保持一致，从而给软件系统带来长久生命力。那么如何建模就是DDD中的核心问题，下篇文章准备探讨建模相关的思考，欢迎提出讨论。