DDD也是牛马
乾坤未定你我皆是牛马，而DDD又何尝不是牛马呢？面试的时候，写博客的时候，和朋友吹牛皮的时候，作为一个技术人，你要是不把DDD搬出来，你都不好意思说你是一个开发，不仅是后端开发在搞这个，前端也在搞这个。装完之后呢，DDD就怕被束之高阁了，landing是不可能landing的，这辈子也不可能landing。是的，博主我也是这样的人。
什么是DDD
DDD，Domain-Driven Design，即领域驱动设计，用领域建模的思想去进行业务设计或技术设计。
几年前，也没有几年前，毕竟我才工作四年，也就18年我毕业的时候，DDD还是蛮新的东西，起码你在找工作时，大家平时交流中时，是很少谈论这个东西，那时候JVM是蛮火的，面试基本都会问JVM，现在很少问了。而这两年，我看很多岗位描述上都要求有DDD相关经验。其实也蛮喜新厌旧的，毕竟在程序设计思想这块，面向对象曾经才是老大哥，基本面试都会问面向对象三大机制，或者设计原则，或者设计模式，此时单例模式表示很淦，都被你们整出了7种写法了。
时过境迁，技术人不迎头赶上，迟早要被拍打在冷冷的沙滩上。
面向对象和SOLID原则
要说DDD，我们要先聊聊面向对象的设计原则即SOLID原则，后面谈到设计模式时，默认也是面向对象设计原则的体现，不纠结某个设计模式体现了什么设计原则。SOLID原则如下所示：
S即单一职责原则（Single Responsibility Principle），答应我，一个类就干一件事，别多管闲事。
O即开闭原则（Open Closed Principle），每次新需求，你都把所有类修改一遍，你敢上线发布，测试敢吗？到底要回归哪些流程？能不能多开些扩展口子，新需求来了就扩展一下口子。
L即里氏替换原则（Liskov Substitution Principle），爸爸都说了，这个方法是a+b，到了你那，就变成a-b了，爸爸不要面子的吗？
I即接口隔离原则（Interface Segregation Principle），答应我，一个接口就约定一件事。
D即迪米特法则，依赖倒置原则（Law of Demeter，Dependence Inversion Principle）迪米特法则，不该知道的不要知道；依赖倒置原则，想做甲方爸爸，你就要学会定义接口。
SOLID原则和其他面向对象设计原则我先不做过多解释，后面我们在聊DDD的时候也会谈到这些原则，我也会进一步做解释。其实在这里，我已经表达出了我这篇博客的核心观点，也是我要传递的想法，领域即对象，领域建模即对象建模，领域驱动设计（DDD）即面向对象设计（OOD，Object-Oriented Design）。就如同一个剧本，换了演员和背景，一切好像又是新的剧情，但核其实还是那个核。历史就是个轮回，谁说不是呢。
这里我要表明我对DDD的看法，DDD是一种业务设计思想（不仅仅是开发，对，说的就是产品，你们也要懂点DDD），是一种业务认知的方法论，它给出了一种认识业务，并剥离开技术实现的可能性（对，可能性，因为知道了也无法landing），即DDD是一种将核心业务规则与具体技术实现解耦的设计思想。这里提到的解耦也是一种程序设计方法，当然也是面向对象的设计方法。
DDD三驾马车
DDD主要分为三大块，分别为架构设计，战略设计和战术设计。
架构设计主要涉及到的核心思想是分层，当然分层基本是所有架构设计采用的思想，比如计算机网络中的七层架构，MVC三层架构，公司组织架构等等。
战略设计主要涉及到通用语言，领域划分（domain，核心域，通用子域，支撑子域），限界上下文（bounded contex），上下文映射图（context map）。
战术设计主要涉及的概念有实体（entity），值对象（value object），领域事件（domain event），领域服务（domain service），应用服务，仓储/资源库（repository），聚合（aggregate），聚合根（aggregate root），工厂（factory）。
具体的含义我不做过多解释，后面博客我们会继续聊如何进行DDD设计，今天我们只聊DDD和面向对象设计之间的关系，如何从面向对象的角度看DDD，让DDD不再高大上，不再神神秘秘，让DDD成为一种显学，人人都会DDD，人人都是DDDer。
DDD与面向对象
DDD本质是面向对象，只是换了更高一层的说辞去包装了一遍。
我们在架构设计中谈论各种架构范式，但始终脱离不了依赖倒置原则，这是DDD架构设计的核心。依赖倒置原则就是面向接口编程，什么是接口，接口即规范。谁定义了接口，谁就是游戏规则的制定者，其他实现接口的开发者都是纯纯牛马，纯纯打工人。我们把核心接口都定义在领域层，让领域层成为核心层，控制流从各个方向指向了领域层。端口适配器模式即六边形架构，直接在命名中就点出了面向接口原则，什么是端口，其实就是接口，适配器模式是做什么用的，就是转换接口，将老接口换成新接口。
接下来，我们再讨论战略设计部分，什么是领域划分？如何进行领域划分？划分原则是什么？不就是单一职责原则吗？每个业务域负责一个核心业务能力，让每个模块以及模块与模块之间形成高内聚，低耦合的一种关系，每个子域内聚在一起形成一种业务能力，子域与子域之间是低耦合的，子域提供的能力通过RPC或者HTTP进行交互。也就是说，领域划分的原则是单一职责原则，领域之间的关系是高内聚低耦合的。以上也就是战略设计的核心内容。
最后我们再聊一聊什么是战术设计，这一层更接近代码编写了。我们在领域建模过程中强调的实体值对象，其本质就是充血模型，让每个实体具备业务规则，而不仅仅像MVC时那样，变成了数据库记录承载者，即对象关系映射（ORM），这违背了面向对象设计的原则。对象是属性和方法的封装，其中属性是数据字段映射，而方法是该对象所代表的业务规则，而不仅仅是数据承载容器。至于领域事件，我就不提了，核心是解耦的思想，其实现方式可以是观察者模式，也可以是消息队列。聚合则是将几个紧密相关的实体组合在一起，形成了一种同生共死（you die i die，you live i live）的关系。几个相关的对象组合在一起，就像一家人，那么这时创造对象就会比较繁杂，需要同时构建几个对象，这时候工厂设计模式就发挥作用，繁杂重复的构造逻辑由工厂（factory）整合起来了，你要创建对象的话，就调用一下工厂提供的接口吧，一家人在一起就要整整齐齐。
还剩下repository（仓储/资源库），其实对多数据源开发来说，repository蛮重要的，它是一种接口即面向接口编程，当我们在领域层定义好了数据的接口时，那么不管基础设施层采用什么技术手段进行数据储存，如redis，mysql，oracle，hbase等等，我都不再关心，你只要按照我的接口进行实现就好。而传统实现中，如MVC，传统DDD四层架构，MVC是service层依赖dao层，也就是说，核心服务层依赖了底层数据层，底层数据的实现技术发生变化，那么service就要变，此时在service定义接口的话，就可以实现依赖反转（倒置），service就不要再做任何改变了。当然这也是Spring IOC的核心思想，实现方式不同罢了。
