DDD.实践思考随笔

目录

微服务为什么用DDD

领域

限界上下文

实体和值对象

聚合和聚合根

​​​​​​​领域事件

​​​​​​​分层架构

​​​​​​​架构模型

​​​​​​​中台：数字转型后到底应该共享什么

---

​​​​​​​微服务为什么用DDD

微服务最大的问题是拆分问题，会导致过度拆分而无法上线。而DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

微服务有服务识别，服务制约，服务管理。 DDD解决的是微服务的识别和制约，即边界划分。 

微服务更关注技术落地，DDD更关注怎么做模型抽象。

淘宝原来是单体应用，访问量上去了，开始大型机，商用WEB SERVER和ORACEL，但成本太高，只好拆分利用免费的MySql，Tomcat，小型机。公司发展，淘宝，天猫等不同部门对部分模块进行了重复实现，比如,文件管理服务，消息中心服务等。同时也产生了信息孤岛，各部门数量不能融合。因此提出中台，将公司所有数量，功能聚合。相当于原来一个公司每个部门都有研发部，现在简历了一个研发中心。而中台需要对整个公司服务，单体应用肯定扛不住，还得用微服务架构风格，那公司业务那么多那么复杂，把那些业务逻辑放下一个模块服务实现呢？指导思想就是DDD，一个业务领域的业务放在一块，用一个或者多个微服务实现。 怎么实现，战术层面，DDD确定了跟微服务技术架构的映射，指导你怎么编代码。

DDD识别服务，微服务是架构风格，微服务技术栈中有个叫SpringClound来落地，实现微服务是为了应对高并发高可用，和微服务同时出镜的是敏捷，敏捷是一种思想，需求不确定，那就不要一次输入，飞多个迭代做，中间还能有调整的机会。团队怎么进行敏捷开发呢？Scrum！当然敏捷还有其他的实践方法论。

怎么上手DDD，杀猪杀屁股一人一个刀口。激进派做法，不管理解不理解思想，直接把DDD那套代码结构搬过来再说，好处是上手快，缺点是只知其然不知其所以然，貌合神离。由上述可以看出，会微服务技术栈+较好的抽象能力，也可以解决服务识别和制约问题，也可以说，用了DDD战略层面内容，当然抽象哪都需要，说是DDD的内容有点不要脸了。个人暂时观点，从业务领域抽象为指导思想，落地微服务，然后在逐渐借鉴DDD战术层面的技巧，不要为了DDD而DDD。 保守派的做法！  

​​​​​​​领域

领域、子域、核心域、通用域和支撑域

DFD对应面相过程的单体应用设计，用例图对应面向对象设计，DDD是面相SOA的设计方法论。思想都是: 自顶向下逐层分解，分治思想。领域就是模块，子域就是子模块。核心域就是核心模块，通用域也是几个模块通用的模块，支撑域是对几个模块有支撑作用的，通用和支撑的区分是通过判断，一个模块是否被另一个模块依赖，如果子模块被上层看不到则是支撑，如文件存取，数量读取。如果一个模块只是所有模块的共用才进行的独立，在上一层是看得到这个模块的，那么就是通用，比如认证鉴权。不同的业务场景划分分类也不同，不同类型的域对待的策略不同，在资源紧张时有效保证核心域的开发。

是不是感觉这些东东不说出来你也懂？这就是为什么DDD在03年提出，现在火的原因，单体应用时大家都这么做，只不过不这么说，多学些概念没啥用，可复杂业务的微服务分格架构 或者 复杂的单体转分布式服务架构 就遇到了领域重新识别和管理的难题，DDD能较好的解决。 所以说DDD也是有他的适用范畴滴

限界上下文

通用语言和上下问边界

一个东西在不同的领域内叫法可能不同，所以需要统一术语，当然得说你边界，什么范围内叫租户什么范围内叫机构。术语的语意背景就是上下文，这个范围边界就是上下文的边界。通常一个上下文就可以对应一个领域或者子领域，实现时就对应一个微服务。

对应面相服务的服务识别和制约，制约即是定义边界，这就对应上了。

​​​​​​​实体和值对象

实体，是一种具有生命意义的对象，他有属性，操作，有唯一ID，比如订单，员工，货物等等。 在设计的时候可以是一个小模块/领域，实现的时候可以是一个类或者一个包，一个微服务。 区别于在设计阶段就开始做ER建模不同，DDD更重视实体识别和设计，而后才是对实体的持久化，当然这样更容易违反关系数据表的设计范式，选择是没关系，能用就行。

值对象，是一种特殊的实体，他没有生命周期，没有唯一ID，只能做实体一个属性，不错的时候可以是外键，如果不做查询，可以序列化一个JSON字符串存储，更新时整体替换。

​​​​​​​聚合和聚合根

聚合是最小的业务单元，业务是由内部的多个实体组合完成，聚合根是聚合的管理者，对外接口和聚合内实体的持久化操作。
聚合是逻辑抽象概念，一个微服务可以包含多个聚合。聚合之间尽可能不要join数量，而是使用调用完成数据的聚合。

聚合内数量使用强一致性，聚合外保证最终一致性

尽可能使用小聚合，方便业务的重组和扩展

聚合怎么抽象，从实体然后分组，或者从顶向下逐渐分解。 这都是对现有业务的分析，对增量模型怎么做是个挑战

​​​​​​​领域事件

领域内强一致性，领域外最终一致性。一个微服务包含一个或多个领域模型，一个事物保证一个领域的持久化。

领域事件就是解决领域外最终一致性机制。可以解决实时调用的压力，也可保证领域的完整性。

​​​​​​​分层架构

分层架构以及演进

三层架构和DDD分层架构的映射

使用分层架构对微服务进行演进

​​​​​​​架构模型

DDD分层架构，整洁架构，六边型架构都是聚焦领域，以分层实现领域和应用的逻辑分离，资源和逻辑代码的分离。

不同点是，整洁架构更关注依赖关系，六边形架构更关注服务对外的形态是用不同端口提供服务，分层则更注重分层。

聚焦领域，一个公司的业务不大变化，领域相对稳定。需求不确定可以通过前端变化和应用层业务的重新编排实现。 这个相对稳定的模块，就称为中台。中台分为项目级和企业级，项目级中台，可以通过一个微服务来做业务的编排和服务的调用，而企业级就需要单独独立出来一层，来做编排和对外层需求的适配。

​​​​​​​中台：数字转型后到底应该共享什么

中台源于平台，平台只是从功能的角度来复用，中台则从企业战略的高度，抽象出公司的核心业务能力建设的平台，具体业务则由前台来编排。中台分为业务中台和数据中台，数据中台可以用数量仓库，大数据技术进行采集，分析和融合，主要的作用是为了打通微服务导致的数量孤岛，为业务中台，前台做数量支撑，同时分析出的数量反推业务的发展和创新。 DDD强调的是建立高内聚的领域，符合建设中台思路。

如何用DDD重构中台业务模型

DDD指导企业信息系统数字化转型有两种策略，从上到下，从下到上，这是具体方法，对应信息化理论就是，推到重来，迭代演化。实际情况是一个公司刚开始业务领域不明确，也没资源去建立一个大中台，所以更多的是演化。演化的核心就是保证现有业务为前提，提炼和沉淀通用领域，重建核心业务领域，逐渐替代和支持分散在各个部门的核心业务系统。 刚学习软件时听老范说，做系统时就是先把系统涉及到的单子，名词全部罗列收集，然后归类，这个过程就看抽象能力了。其实DDD就是归类的具体方法论，内力还是抽象能力，那些单据名词就是聚合或者属性，归类就是划分领域，类型的边界就是这叫限界上下文，每一个聚合有个管理员就是聚合根，单据就是实体，属性或者一些字典数量存储就是值对象。有了思想代码自然现成，只不过很多人想的是直接告诉我怎么做，不想去思考罢了！根子原因是，企业会为会怎么做买单，不会为会为什么买单，浮躁之风无处不在。

边界：微服务的各种边界在架构演进中的作用？

逻辑，代码，物理 三种边界
逻辑边界是指业务抽象的边界，对应聚合的边界，多个聚合形成的微服务间的业务边界
代码边界是从代码纬度来区分不同聚合，微服务的隔离边界，也就是代码目录
物理边界强调物理隔离，即进城隔离，微服务就是进程隔离，通信，调用依赖关系
严格要求的边界是为了隔离，隔离是为了重组代价更小，微服务的重点是更容易迭代，无论是扩容，局部重构，重组聚合