DDD 领域驱动设计简单介绍

不同于其它的架构方法，领域驱动设计DDD（Domain Driven Design）提出了从业务设计到代码实现一致性的要求，不再对分析模型和实现模型进行区分。也就是说从代码的结构中我们可以直接理解业务的设计，命名得当的话，非程序人员也可以“读”代码。DDD不仅是统一语言、以业务驱动系统设计，在熟悉新业务和系统重构时，领域驱动设计思想更能很好快速梳理业务。如下图领域驱动设计是以领域(业务模型)为核心，通过数据代理层（Repository）来与其他系统交互，来驱动整个系统架构设计。

领域驱动设计优势和劣势

DDD不是银弹，它只是复杂性业务的一种解决方式。DDD解决了系统设计的‘复杂性’，DDD设计思想本身又存在复杂性。

优势

• 系统演进更方便

随着业务的变化、系统设计也要演进升级。好的架构设计一定演化来的，不是一开始就设计出来的，但系统演进过程中的成本，一定是最开始的设计决定的。一个健康公司的成长，业务横向、纵向会发展的会越来越复杂，支持业务的系统也一定会越来越复杂。在领域驱动设计中，域模型对应的是业务模型，是系统架构的内核，通过域模型来驱动与外界的交互。

• 业务复杂性变化的演进

域模型可能是简单新增属性或action就能支撑整体的业务发展。企业订餐的业务系统要同时有用户端、运营端、企业端、商户端的数据展示和操作，当业务演进出一个新功能时，这四端系统可能都要同时改造支撑。在领域驱动中，系统的域模型是同一套，只需在领域层进行改造，即可同时支撑四端。

• 业务数据量变化的演进

公司业务数据量的变化后，现有的架构往往很难支持业务的发展，一定会进行新的技术选型支持业务。在DDD中，域模型为内核，在内核外的一层是代理层，通过这层代理来抽象透明化掉业务模型对系统底层设计的感知。比如原本数据量很小，一个简单的搜索直接使用MySQL like 模糊查询即可满足，在数据量巨大这种方式无法满足的时候，需要使用ES这种专业的搜索技术来实现，这时候仅需要在数据源层把原本指向数据源MySQL改成ES即可，业务代码全程透明无感知，可以达到给正在飞行的飞机换引擎的效果。

• 更方便测试

对于测试（包含开发自测）来说，流程跑不通是痛苦的，由于IO造成阻塞而非系统逻辑是更痛苦。测试的时候最喜欢的纯函数测试，不依赖任何IO(不包含机器内存层面)，DDD设计思想是天然的在代码上把纯函数和普通函数区分开，Repository层是非纯函数，在Repository层Mock掉，整体系统就成了纯函数系统，对测试在Mock数据、切换数据源是非常方便和友好的。

劣势

• 系统改造成DDD复杂

我们常用的架构基本都是MVC三层架构方式，在常用的MVC三层架构中基本所有的业务逻辑都在service层中，并且是按service功能属性设计的Service层，现在要进行DDD思想开发，需要打破原有的设计，有些严重的还必需要进行重构设计。

• 团队开发熟悉DDD思想困难

改变自己比较困难，对别人产生影响更加困难。一个开发团队如果之前对DDD都没有了解，要推进和对团队产生影响是一个艰难的过程。

看透问题的本质是DDD的最核心价值我们过去过于强调架构而忽略了DDD建模的重要性，架构从系统实现上来看固然是重要的，但是架构不是一成“不变”的。我们应将重点放在领域模型上，领域模型是相对“静止”的，并且能产出更多的业务价值。