一、前言

一般状况软件规划开发首要分两种：

【瀑布式】经过许多的事务剖析后，会根据现有需求整理出一个基本模型，再将成果汇总传递给开发人员构成需求文档；咱们发现瀑布式研制的方法最大的缺陷就是反馈频率低，并且终究交付成果和预期或许发生会较大误差。

【灵敏式】前期同样也需求经过许多的事务剖析，但灵敏式的中心要点不是快，简略地来说，灵敏开发并不追求前期完美的规划，而是力求在很短的周期内开发出产品的中心功用，尽早发布出可用的版别，后续不断迭代晋级，一起拥抱变化。

灵敏式研制的缺陷，或许存在许多需求或事务模型改变、终究导致体系保护成本会变大，对开发和体系弹性性各种要求也比较高。

二、DDD 是什么

范畴驱动规划，通常需求进行许多的事务的常识整理，然后软件规划最后软件开发，在事务常识整理整理进程中，必然会构成某个范畴常识，根据范畴常识一步步驱动软的规划，就是范畴驱动规划的基本概念。

在微服务架构的形式下，DDD 又一次走进咱们视界，成为微服务架构的指导思维。DDD 体系比较巨大，最中心的是范畴距离的区分，对于咱们开发来讲，学习 DDD 思维，应用 DDD 战术东西，对于提高咱们的事务架构才能，驾御杂乱事务体系的规划都会有一定提高和协助；

一起 DDD 也是一种架构规划方法论，经过工作风暴、让咱们可以更明晰发现和了解事务价值，笼统化构建通用言语，帮咱们规划出明晰的范畴和距离，再经过距离区分将杂乱事务的范畴化，范畴驱动规划并不是下降事务的杂乱性。

三、DDD 有什么价值

明晰的事务模型距离，可以让咱们更专注事务视角，够协助事务人员和开发人员整理清楚杂乱的事务规矩，开发出来的软件也可以精确表达事务规矩；

经过树立通用言语、可以削减产品与研制、事务人员之间的交流距离，在不断完善范畴模型进程中可以运用新的东西战略技能、战术技能， 让咱们更明晰的区分模块与依靠、进行事务建模或应用于微服务拆分等。

四、DDD 中心支柱是什么

通用言语和限界上下文是 DDD 两大中心支柱。

怎么构建通用言语，其最大的应战就是需求咱们花费时刻、精力去思考、剖析事务和专家交流构建改进通用言语，终究达到共识，再经过工作风暴，划清事务距离、剖析范畴模型、辨认出限界上下文。

五、DDD 中心概念

让咱们先开始认识 DDD 中重要概念包含的内容：战略规划、战术规划、范畴、限界上下文、实体、值目标、范畴服务、聚合、工厂、范畴工作、工作风暴、仓储等，接下里咱们讲结合事例为我们逐个讲解：

六、DDD 战略规划

战略规划是让咱们从事务视角动身，树立事务范畴模型，区分范畴距离，树立通用言语、辨认限界上下文的进程。

怎么实现战略规划,就是经过工作风暴，选用用例剖析或场景剖析拆解事务，树立范畴模型，整理范畴目标之间的关系；

而工作风暴进程必定会发生各种实体、指令、工作等范畴目标，咱们将这些范畴目标归类构成聚合、一起区分限界上下文，树立范畴模型，这是一个从发散到收敛的进程；

战略规划思维

战略规划思维、需求考虑问题空间与处理方案空间：

什么是问题空间， 其实每个事务都有一个对应的事务模型，其间需求留意的事务模型不是范畴模型，在咱们规划事务模型的进程中无需重视软件规划思维（比方目标的笼统、承继、存储、功能)，而是咱们需求从事务自身动身，剖析提炼事务距离范围、事务概念和确认事务概念之间的关系；

什么是处理方案空间， 咱们在进行DDD范畴驱动规划实践时，需求进行需求剖析、范畴区分、范畴建模等工作，体系落地实时则需求考虑处理方案，可是假如这个处理方案过大，其坏处必定会导致各模块或组件都耦合一起，不利于整个体系的保护、演进、弹性。

所以咱们需求把处理方案拆分为一个个独立【范畴】和【处理方案】,范畴和处理方案本别代表问题空间 和 处理方案空间。

处理方案该怎么拆分？需求咱们剖析事务结合准则终究得出一个综合考虑后的拆分成果。所以，处理方案的拆分是多维度的，或许需求从体系功能，架构，弹性性等视点拆分，多考虑一些要素，使咱们更好的进行处理方案空间的拆分。

【范畴模型】 ,是DDD软件规划方法论中的中心概念，它是事务剖析、软件规划的综合成果，是一个体系规划模型。范畴模型存在于某个处理方案空间里。

所以，任何一个范畴模型，都是在特定的距离内才有意义，一起范畴可以区分巨细，范畴区分，而区分出来的【子范畴】简称子域，每个子域对应一个小的问题域和事务；

因为各个子域的重要性不同，所以才有了中心子域、支撑子域的区分；限界上下文， 就是为了表达上面某个处理方案的上下文距离。

七、DDD 战术规划

图示 DDD 战术建模元模型体系图， 经过元模型咱们会对【战略建模】进程中辨认出来的问题子域进行笼统， 元模型图用于描绘怎么去创立一个 DDD 的模型。

DDD 的战术建模包含如下内容：

实体-Entity、值目标-Value Objects、范畴服务-Domain Services、范畴工作-Domain Events、模块-Modules、聚合-Aggregate、资源库-Repository

战术规划准则

图示战略规划思维脑图。

事务模型并不是范畴模型，而是事务概念，其间心是提炼事务中心价值。

范畴是事务距离，是问题空间和事务距离，或许是不同子域，是一个个问题域（ 中心域 + 支撑子域）的组合。

处理方案需求进行事务剖析、范畴区分 、范畴建模，其准则是根据事务和规划准则形式、进行多维度考虑(如体系功能、架构演进等)。

范畴建模是事务模型 加 模型提炼的进程，而模型提炼需求咱们依靠规划思维准则。

限界上下文是距离，有了这个距离咱们才可以精确表达和界说距离内的范畴模型中一切目标概念意义，而缺失限界上下文距离，则会造成对同一概念在不同上下文的了解误差。

八、通用言语

针对对同样的范畴常识，不同的参与人物或许会有不同的了解，为了防止交流距离，DDD 范畴建模进程中就呈现了“通用言语”和“限界上下文”这两个重要的概念也是 DDD 两个中心支柱。

通用言语是在经过团队交流、交流、洽谈构成的一致界说，其效果可以简略、明晰、精确描绘事务寓意和事务规矩的一种言语.通用言语也包含事务术语,可以直接反映在代码逻辑,其间通用言语中的名词可以给范畴目标命名、通用言语中的动词则表明一个动作或一个对应范畴工作或许一个指令。

通用言语贯穿 DDD 的整个规划进程，根据它，咱们就可以开发出可读性更好的代码，将事务需求精确转化为代码规划。

那么怎么构建通用言语:工作风暴

九、工作风暴

工作风暴，是一种快速探究杂乱事务范畴建模的实践, 从范畴中重视事务工作，进程中团队经过充分讨论，一致言语，找到范畴模型。

经过收集寻觅范畴工作、指令、人物，聚合、区分范畴，辨认限界上下文，区分子域（中心域、支撑域、通用域、或其他子范畴）。

工作风暴进程回忆

以上都是根底概念、接下来咱们将结合事例讲解

1、剖析订单问题空间、确认处理方案空间

酒店买卖在落地 DDD、深入剖析订单问题空间，从酒店订单、搭售和预售等订单流程，笼统剖析，从用户生单、落地存储、付出退款冻结、交互渠道付出中心、订单完结通、结算等事务流程中，有高度重合现象。抽取大致以下 7 点一起特征，如产品快照、规矩解析、资金抽取、付出表单、交互付出中心、履约流程和逆向流程等。

经过高度笼统问题域构成处理方案空间，构建订单范畴模型、构成安稳区间、确认不同问题域处理方案空间的巨细。如图示

2、辨认人物、指令、工作

怎么寻觅范畴工作

一个范畴工作可以了解为是发生在一个特定范畴中的工作，可是并不是一切发生过的工作都可以成为范畴工作。

一个范畴工作有必要对事务有价值，有助于构成完好的事务闭环，也即一个范畴工作将导致下一步的事务操作。

图示：酒店买卖先住后付的事务流程、经过工作风暴、场景剖析、界说要素一起结合订单事务正向、逆向流程、履约流程等的全貌整理；

辨认订单流程效果人物、用户、代理商、运营、酒店等多种事务人物；

了解不同的事务人物在事务流程中需求发生什么工作、下一步触发什么动作；

经过以上流程、辨认出了创单工作、授信工作、降级工作、撤销工作、离店工作、扣款工作、欠款工作、还款工作、完结工作、催收工作和订单履约工作几十个范畴工作；

3、确认聚合、划定距离

酒店买卖 DDD、辨认区分报价范畴、订单范畴、付出范畴、履约范畴、调度范畴等，其间

订单聚合根：处理信息流、资金流、状态、父子单事务、逆向流程等、封装处理订单问题

付出聚合根：处理付出事务分账、资金正向、逆向流程、与付出中心交互、规范 API 输出、幂等性考虑等、封装处理资金问题

履约聚合根：处理订单履约事务、确认、审核、封装处理 OFC 问题

聚合准则包含：

准则1

假如范畴目标不能作为一个独立存在的目标。它应该被另一个范畴模型持有和运用，可以考虑把两个模型合起来， 构成一个聚合。

在最上面的模型就是这个聚合的聚合根，其之下的模型都是它的实体或值目标找到范畴模型以后，咱们应当就可以比较轻松地区分子域和限界上下文了。

在区分限界上下文的时分也可以反过来查验范畴模型和通用言语的正确性。假如发现一个模型有歧义，应该从头思考这个模型，必要时进行拆分。

a. 双向依靠：上下文之间缺少一层未被确认的上下文，或许两个上下文其实可被合为一个；

b. 循环依靠：任何一个上下文发生改变，依靠链条上的上下文均需求改变；怎么确认明晰的BC，依靠事务架构才能、丰厚的行业常识、体系剖析才能；假如是生疏的范畴、可以经过灵敏迭代不断调整范畴模型、演进修正终究得到合理的BC；

准则2

聚合内,需求确保强一致性，其方法需求考虑聚合根实体一致存储；

聚合间,可以考虑经过异步工作驱动、结合重试补偿达到事务终究一致性；

3.1 订单范畴

图示：酒店买卖订单范畴 聚合根界说、包含实体、值目标、范畴服务规划；

在规划和构建聚合根、需求确保和遵守以下准则：

准则1【一致性准则】 聚合是由在一致性距离内的实体和值目标组成，创立一个聚合最基本的准则是范畴目标的群集有必要根据范畴不变条件。范畴不变条件是指不管何时数据发生变化都有必要满意的一致性准则，这个一致性准则一定要满意真正的事务规矩；

准则2【保持不变条件】要让聚合保持一致性，其组成部分就不应该被外部访问。需求经过为聚合选择一个实体作为聚合根，其聚合根行为方法可以外部进行交互；

准则3【一个事务只修正一个聚合】大聚合会导致事务失败的几率变大，更新抵触变多，假如咱们发现需求在一个事务中修正多个聚合，可以选用终究一致性或其他处理方案；

准则4【小聚合】聚合应该规划的尽量小，大聚合存在以下缺陷：

缺陷1：大聚合会下降功能,因为大聚合会增加额外的查询，或许导致功能下降。

缺陷2：通常会运用达观锁版控机制来进行数据库的改变操作，大聚合或许包含了许多事务责任，当多个指令对单个聚合进行操作改变，并发抵触的几率会变大，事务失败的几率也会随之变大。

缺陷3：大聚合扩展性差，意味着更多的模型会发生依靠关系。

准则5【在距离外运用终究一致性】实现终究一致性的技能手段有许多，可以考虑MQ机制，在工作消费的流程中处理对其他聚合的改变。既可以满意一个事务只修正一个聚合这一基准准则，又可以凭借消息行列中间件供给的失败重试机制，完成终究一致性、确保事务精确性。

酒店买卖拆分订单聚合、付出聚合、运用终究一致性来确保两边状态的一致性，防止大聚合。

3.2 实体

【实体（Entity）】

一个实体模型就是一个独立的事物，具有事务特点和事务行为。每个实体都拥有一个唯一的标识符；

可以对一个实体进行多次修正，修正后的数据和本来或许会不同，但它们依然是同一个实体，因为唯一标识没变。

实体模型分四类

失血模型简略来说，就是目标只要特点的 getter/setter 方法的纯数据类，一切的事务逻辑完全由 business object 来完成。通常在 MVC 形式下一种实体界说的数据模型，仅是一个数据的载体，没有事务意义。

贫血模型 domain object 包含了不依靠于持久化的范畴逻辑，而那些依靠持久化的范畴逻辑被别离到Service层。贫血模型切分的准则是什么呢？可重用度高的亲近关联的放在实体中，可重用度低放在Service中。

模型的长处：各层单向依靠，结构清楚，易于实现和保护。

模型的缺陷：Service 层过于厚重。

充血模型充血模型和第二种贫血模型相似、最大的差异是怎么区分事务逻辑，绝大多事务逻辑都应该被放在 domain object 里面(包含持久化逻辑)，而 Service 层应该是很薄的一层，仅仅封装事务和少量逻辑，不好 DAO 层打交道。

模型的长处：符合 OO 的准则 Service 层很薄.

模型的缺陷：怎么区分 Service 层逻辑和 domain 层逻辑需求规范化，在实际项目中，因为规划和开发人员的水平差异，或许导致整个结构的混乱无序

胀血模型domain object(事务封装，事务逻辑) <—> DAO

模型长处:简化了分层

模型缺陷：domain object 暴露给 web 层过多的信息，许多不是 domain object 的逻辑也强制放到模型中、导致模型的不安稳。

以上模型的分类说到底是粒度的问题：

颗粒度细重用好，但类多、结构杂乱、繁琐；颗粒度粗（爽性用一个类干一切的事）重用差，但类少、结构简略；

传统开发形式，将数据与事务逻辑完全别离，经过 get set 方法改变目标特点，可是违反了 OOP 的三大特性之封装特性。面向进程的编程方法不必运用太多的规划形式和过多的规划，缺少了拓展性;

充血模型的规划要比贫血模型更有难度，需求转化思维，当咱们规划一个杂乱事务场景是需求充血模型DDD、一起也遵从了OOP特性(封装、持续、多态(笼统)，假如一个实体行为方法过多、可以考虑结合事务逻辑拆分和规划模型处理该问题；

3.3 值目标

【值目标(Value Object)】，用于描绘范畴的某个方面而自身没有概念的目标称为值目标，值目标被实例化之后用来表明元素，对于这些元素，咱们只关怀它们是什么，不关怀它是谁。无状态、不可变，没有身份标识，特点可度量或许描绘 当度量和描绘改变时，可以用另一个值目标予以替换。

实体和值目标的差异

3.4 应用服务、实体行为、范畴服务差异

十、理论小结

1：一种细想、一种科学方法论，从战略到战术规划进程是咱们规划思路更明晰、更规范；

2：范畴驱动处理高度杂乱事务的方法，不是下降杂乱度，而是让咱们去思考怎么应对、建议中心安稳的范畴内核模型，有利于常识范畴传承；

3：范畴驱动强调团队和范畴专家协作，树立交流杰出的团队；

4：有助于 RD 提高 OO 思维和驾御杂乱事务体系规划才能，战略规划为咱们供给一种高层视界来审视咱们的软件体系，首要包含范畴/子域、通用言语、限界上下文和架构风格等概念， 战术规划的目的是确保战略的实现；

在 DDD 中，再需求那些无法得到实时更新的规划文，代码就是规划自身；

5：创立行为饱满的范畴目标，将范畴目标作为是服务的供给方，而不是数据容器，多思考一个范畴目标可以供给哪些行为；范畴模型也是随着事务开展不断迭代演化完善、服务用户、做好产品、体现渠道价值。

本文首要环绕DDD范畴驱动规划中心概念和理论，从战略到战术进行了分享总结，希望对我们有所协助，下一篇——咱们结合酒店买卖事务流程，分享酒店买卖DDD范畴驱动施行落地进程及代码层面留意事项和规范、准则。