DDD四层架构实践学习

前言

DDD领域驱动相信同学们最近都会有所听闻，而且很多大厂都是往这方面进行项目的重构，本文会说下本人目前所学习关于DDD的一些实践与心得。以下为网上的DDD概念与同事之前所总结，我觉得比较好所以分享一下。

关于DDD的误区

DDD是解决大型复杂项目的，我们当前业务比较简单，不适合DDD。
DDD要有一个完整的、符合DDD原则的代码结构，这可能增加代码的复杂度，有可能导致项目进度失控。
DDD是一种框架，应该包含聚合根、实体、领域事件、仓储定义、限界上下文等一切DDD所倡导的元素；否则你就不是DDDer。
DDD需要大家严格遵循各自模块的边界，且存在着过多因为解耦带来的看似冗余没用的代码，会降低编码效率，造成“类膨胀”。

DDD离我们很近

DDD是什么？众里寻她千百度，蓦然回首，“DDD是一种可以借鉴的思想，而非严格遵循的方法论”。

对DDD的一些理解

限界上下文：公司里的一个较为核心的系统，有独立的代码仓库，有一个独立的团队负责维护一个系统，工作范围在这个限界上下文里，然后在这个限界上下文里需要对各种核心概念定义一套通用的中文和英文的名词和解释，这就是通用语言，团队每个人对这些中文和英文名词的含义都有共识；

一个团队可以同时负责维护多个系统，也就是多个限界上下文，但是多个团队不能在一个限界上下文里工作，也就是多个团队同时修改一个系统的代码，那是不可能的，一个限界上下文就是一个独立的完整的系统，有独立的代码仓库、数据库、测试代码，独立团队，独立通用语言；

通用语言：比如说订单系统里，有一个类，Customer，对订单系统这个限界上下文里，指的是下订单的用户；对于采购系统里，Customer，指的不是下订单的用户，是批发商进行批量采购的客户，同样是Customer，在不同的系统（限界上下文里），对应的含义是不同的；

在不同的系统对应的限界上下文里，定义出来一批名词（一堆类），代表了这个限界上文里的通用语言，只有这个限界上下文里的几个系统的开发工程师，会按照同样的一批通用语言来理解所有的名词，大家对Customer这个名词的理解是一样

核心域： 如果你的一个限界上下文，也就是一个系统，是公司里极为核心的一个系统，比如说一个电商平台里，商品、订单、库存、营销、仓储、物流、会员，每个大系统都可以是一个限界上下文，都是独立团队维护，都有自己内部的通用语言，然后他们都是公司最为核心的一些系统，这些限界上下文也可以叫做核心域；但是如果是一些非核心系统，比如说什么竞对数据爬虫系统、第三方比价系统、BI报表系统，类似这些，如果不支撑公司核心流程运转，主要是锦上添花的系统，那么他就不算是核心域;

上下文映射：其实就是说子域如何进行集成，也就是各个系统如何通过接口进行集成，你需要把别的系统的一些通用语言里的东西在接口里转换/映射为你的系统里的通用语言，如果是在一个系统里划分多个子域的，那么就是一个系统内部的各个模块间如何通过interface进行集成，不同模块的类如何进行映射和转换;

实体和值对象，说白了就是去建模每个子域里的具体类；聚合，就是如何把实体和值对象聚合成一个关系；领域事件，其实有点类似于系统间进行交互时候的一些核心事件，类似创建订单之类的；

DDD的核心价值

让业务和技术有相同的理解

作为技术，不能自己随便定义代码里的任何一个类名、方法名、参数名、属性名、变量名、接口名、数据库名；业务建模时，应该针对负责的这个系统去进行通用语言的设计，技术团队应该找到业务方，比如说产品、用户、运营，大家一起开会讨论，一起设计这个系统 （限界上下文）的通用语言；

写代码之前，必须进行细化的领域对象的建模，实体、值对象、领域服务、领域事件、行为、数据，全都建模出来，包括实体之间互动的业务流程，这些东西其实都应该设计出来，全部都是根据通用语言来的；

落地写代码，搭建工程，用的技术架构都是之前确定好的技术架构，但是里面具体的类名、方法名、参数名、属性名、变量名、接口名、数据库名，全部都是根据领域对象建模出来的东西来做的；

通用语言，是DDD里最最核心的东西，他其实跟技术无关，完全是业务，业务和技术必须一起制定一套通用语言出来，包括通用语言的中文术语以及英文术语，全部要统一制定，规定术语的含义；

通用语言是限定在限界上下文里面的，在一个限界上下文里面，才是一套通用语言，通常建议是一个限界上下文对应一个系统，而不是所谓的一个服务而已，否则不可能为每个服务都创建一套通用语言；通常都是一个系统对应一个团队，然后他们都用一套通用语言，对应一个限界上下文；

如果要用DDD，最核心的一点改变，就是要大量的跟产品经理，系统用户，或者运营，公司内部其他人，管理层，其他团队，去进行交流，大量的交流，才能把业务真的理解清晰，然后才能让产品、用户和技术团队，站在一起，一起定义一套通用语言出来；

参考资料

DDD源码实战可以看看此github：DDD开源GITHUB

领域驱动设计介绍

DDD目的是对软件涉及的领域进行建模， 以应对系统规模过于庞大而引起的软件复杂性问题。整个过程为研发团队和领域专家一起通过通用语言描述领域知识。从领域知识中提取和划分为一个个子域。包括核心子领域、通用领域和支撑子领域，并在子领域上建立模型，再重复以上步骤，周而复始，构建出类似上图，符合当前领域的模型。

开发目标

• 拒绝小单体，拒绝污染功能与服务，拒绝增加一个月的功能排期
• 设计出高可用、符合互联网高速迭代的应用服务
• 物料化、组装化和可编排的服务。提高人效

服务架构

应用经验