字节面试：请说一下DDD的流程，用电商系统为场景

墨蓝 2024-02-18 09:23 55阅读 0赞

### 说在前面 ###

在40岁老架构师 尼恩的**读者交流群**(50+)中，最近有小伙伴拿到了一线互联网企业字节、如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

> 谈谈你的DDD落地经验？
> 
> 谈谈你对DDD的理解？
> 
> 如何保证RPC代码不会腐烂，升级能力强?
> 
> 用电商系统为例介绍一下领域驱动设计DDD?

最近有小伙伴在字节，又遇到了相关的面试题。小伙伴懵了， 当然，**面试也就挂了**。

这里尼恩给大家做一下系统化、体系化的 DDD 梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，**让面试官爱到 “不能自已、口水直流”**。

也一并把这个题目以及参考答案，收入咱们的 《[尼恩Java面试宝典PDF][Java_PDF]》V122版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取

出了本文，尼恩输出了一个 《从0到1，带大家精通DDD》系列，帮助大家彻底掌握DDD，链接地址是：

《[阿里DDD大佬：从0到1，带大家精通DDD][DDD_0_1_DDD]》

《[阿里大佬：DDD 落地两大步骤，以及Repository核心模式][DDD _Repository]》

《[阿里面试：让代码不腐烂，DDD是怎么做的？][DDD]》

《[阿里大佬：DDD 领域层，该如何设计？][DDD 1]》

《[极兔面试：微服务爆炸，如何解决？Uber 是怎么解决2200个微服务爆炸的？][Uber _2200]》

《[阿里大佬：DDD中Interface层、Application层的设计规范][DDD_Interface_Application]》

大家可以先看前面的文章，再来看本篇，效果更佳。

另外，尼恩会结合一个工业级的DDD实操项目，在第34章视频《DDD的顶奢面经》中，给大家彻底介绍一下DDD的实操、COLA 框架、DDD的面试题。

#### 文章目录 ####

*   *  说在前面
     *  领域驱动设计介绍
     *   *  第1步：战略设计
         *   *  1、业务分析
             *   *  事件风暴业务分析的核心环节
             *  2、领域建模
             *  3、划分边界上下文
         *  第2步：战术设计
         *   *  1、领域服务设计
             *  2、领域分层
             *  3、代码结构
     *  电商的领域驱动设计
     *   *  第1步：战略设计
         *   *  1、事件风暴：参与者、动作以及事件 整个协作流程梳理
             *  2、领域建模与边界上下文划分
         *  第2步：战术阶段
     *  领域驱动设计与微服务的关系
     *  领域驱动设计与敏捷开发相结合
     *  未完待续，尼恩说在最后
     *  尼恩技术圣经系列PDF

### 领域驱动设计介绍 ###

领域驱动设计（Domain-driven Design，DDD）是一种软件设计方法，该方法的核心思想是将业务领域作为设计和开发的中心，强调对业务领域的深入理解、业务语言的建模以及领域对象的设计和实现。

这样可以更好地将软件设计和业务需求紧密结合起来，从而提高软件的可维护性、可扩展性和可重用性，使得软件更加贴近业务需求。

DDD设计的两个阶段包括两部分，战略设计部分和战术设计部分：

**第1步： 战略设计**

战略设计主要从业务视角出发，包括了业务场景分析、领域建模、划分边界上下文三个阶段。限界上下文可以作为微服务设计的参考边界。

**第2步：战术设计**

战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，

战术设计包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的技术设计和技术设计。

#### 第1步：战略设计 ####

在战略设计阶段，我们最主要的过程大致包括了业务场景分析、领域建模、划分边界上下文三个阶段。

实际上战略设计是 DDD 过程中的核心步骤。

##### 1、业务分析 #####

在这个阶段我们所有做的就是进行全面的业务梳理，把业务中涉及到的所有细节都梳理出来，为后续进行领域建模分析提供足够的、全面的业务输入。

战略设计 经常使用到的业务场景分析方法主要包括

*  用例分析法
 *  事件风暴法
 *  四色建模法。

一般使用事件风暴法。

**事件风暴**是一种快速，轻量级且未得到充分认可的**群体建模技术**，它对于加速开发团队而言非常强大，有趣且有用。

###### 事件风暴业务分析的核心环节 ######

这里我们使用事件风暴进行业务场景的分析以及梳理。

**（1）事前准备**

在进行事件风暴之前我们需要进行一些准备，主要包括贴纸、笔以及讨论的会议室，

会议室中最好不要有椅子，目的是想让大家都能够站立在一起、全神贯注的去进行业务讨论。

**（2）邀请参会的人**

会议的参与方主要包括用户、产品经理、PD、研发、测试、架构师等。

其中，PD为产品设计师，也可能叫产品规划师、需求分析师、小产品经理。

PD侧重于将对应用做功能级的设计，在这个模块上，PD类似是一个小产品经理、模块级别的产品经理。

架构师（系统分析师）会与PD紧密合作，架构师 这时候开始考虑技术可行性，性价比。

PD的职位描述：

（1）调查市场并研究需求，形成市场需求文档。

（2）负责新产品设计，拟定设计规划和方案。

（3）负责新产品的原型设计。

（4）组织产品开发团队，协调资源，跟进产品的开发，保证日程进度。

（5）分析产品运营数据，收集运营意见，及时调整产品形态，优化产品，并提出合理的运营建议。

（6） 以用户体验为中心，改进现有产品，或设计新产品。

**（3）业务讨论**

首先确定我们今天需要讨论的业务是什么，目标是什么。

咱们业务场景中，如果讨论的业务就是电商，那么，目标就是完成业务梳理，确保没有业务方面的理解 gap，在团队中达成业务理解的的一致性。

事件风暴过程需要问题驱动，一般通过提问的方式来驱动交流。

**a、分析业务中的事件，搞清楚事件发生的前因后果**

*  什么动作会导致当前事件的发生，
 *  当前这个事件发生后又会导致怎样的后果。

这些我们都需要梳理清楚。

还有一点需要注意， 需要全面梳理

*  不但要关注正常的业务流程，
 *  还要关注异常的业务流程。

**b、寻找业务逻辑和业务规则**

**注**：在进行事件风暴过程中，所有的参与人都要全身投入整个过程，

大家都是站立形式，聚焦全部注意力，

大家都放下手机以及电脑，一起参与整个业务梳理过程，只有这样，事件风暴才可能有比较好的效果。

在前面的事件风暴业务梳理中，我们已经把电商业务涉及到的参与者、动作以及事件等都进行了全面的梳理。

参与者、动作以及事件 整个协作流程，是一个粗粒度的 业务流程， 非常粗。

##### 2、领域建模 #####

那么接下来我们就要在此基础之上，进行细粒度的 领域建模，这是整个 DDD 的核心。

DDD领域模型 细分为两步骤，第一步是发散，产生很多**实体、命令、事件**等领域对象，

DDD领域模型 细分为两步骤，第二步是收敛，我们从不同的维度对进行聚类形成聚合，建立最终领域模型， 这是一个收敛的过程。

**（1）发散阶段：领域对象分析**

领域对象分析，也就 **实体、值对象、领域事件、领域命令**的分析。

**（2）收敛阶段：构建业务聚合**

完成领域对象分析之后，我们需要构建业务聚合。

想要构建聚合，那么首先就要在实体中找到聚合根。

来看看，一个 聚合根的特点：

*  聚合根一定是实体，那么它具有全局唯一的标识，
 *  聚合根是具备生命周期的
 *  聚合根需要专门的模块来进行管理。

##### 3、划分边界上下文 #####

获得了整个业务流程中的所有聚合后，我们需要更具业务语义上下文将具体的聚合划分到对应的上下文中，

*  **域的拆分**
    
     *  按业务抽象进行划分
     *  一个业务拆分成几个独立的域，每个域又可细拆成不同子域
 *  **防腐**
    
     *  一个域在访问其他域的模型时，把获取到的模型做层转换映射到自己域的模型中（不直接使用别的域模型作为自己域模型中的一部分）
     *  防止源域模型发生变更，依赖源域模型的调用方，在需要源域模型新功能时，必须要全局依赖修改，才在能兼容
     *  防止域上下文不一致产生的冲突
 *  **限界上下文之间的映射关系**
    
     *  合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
     *  共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。
     *  客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。
     *  遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。
     *  防腐层（Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。
     *  开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。
     *  发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。
     *  大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。
     *  另谋他路（SeparateWay）：两个完全没有任何联系的上下文。

#### 第2步：战术设计 ####

在战略设计阶段，我们通过事件风暴法对整体的业务进行了全部的梳理，同时构建了领域模型，以及划分了边界下文。

那么接下来我们就要将领域模型映射到工程结构，以及代码中实现最终的实现落地。

另外在这个阶段实际还有很多细节需要明确的。

##### 1、领域服务设计 #####

需要哪些领域服务，领域服务依赖哪些属性，依赖哪些实体，依赖哪些值对象，这些都是需要在战术设计阶段明确下来。

##### 2、领域分层 #####

在领域分层方面，可以按照cola分层结构来进行，这个后面结合cola框架进行说明。

##### 3、代码结构 #####

当我们把领域对象进行进一步的细化之后，同时把对应的领域服务敲定之后，我们可以把这些分析后的内容映射成工程分层后的代码了。

所以，后续就进入到阶段了，还有很多工作要做，比如详细设计、编写代码以及功能测试，

特别实在详细设计阶段，我们还要涉及很多的细节问题的敲定，比如数据库表的设计、比如使用什么 MQ，用不用缓存，怎么保证缓存和数据库的数据一致性问题，分布式服务有没有分布式事务的问题，应该怎么解决？

有没有服务幂等问题，应该怎么解决？

这些都是需要在详细设计阶段进行确定的。

因此 DDD 就像是框架，通过它把业务映射成为领域对象以及领域服务和领域事件，再把这些领域相关内容再读映射为实际的代码。

使得我们的服务更加的逻辑清晰以及扩展性更强，但是分布式的技术实现细节，我们还是需要有对应的解决方案来进行解决。

### 电商的领域驱动设计 ###

#### 第1步：战略设计 ####

##### 1、事件风暴：参与者、动作以及事件 整个协作流程梳理 #####

大致可以梳理出下面的参与者、动作以及事件

1.  **订单创建事件**：当用户下单后，系统需要创建一个新的订单，并触发订单创建事件。
2.  **订单支付事件**：当用户完成订单支付后，系统需要将订单状态设置为已支付，并触发订单支付事件。
3.  **订单发货事件**：当商家完成订单发货后，系统需要将订单状态设置为已发货，并触发订单发货事件。
4.  **订单退款事件**：当用户申请退款并经过审核后，系统需要将订单状态设置为已退款，并触发订单退款事件。
5.  **商品上架事件**：当商家将商品上架时，系统需要将商品状态设置为上架，并触发商品上架事件。
6.  **商品下架事件**：当商家将商品下架时，系统需要将商品状态设置为下架，并触发商品下架事件。
7.  **库存变更事件**：当用户下单后，系统需要检查商品库存是否充足，并对库存进行相应的变更，并触发库存变更事件。
8.  **物流状态变更事件**：当订单状态变更为已发货时，系统需要记录物流信息，并触发物流状态变更事件。

通过对领域事件的记录和处理，可以在电商系统中实现更加复杂的业务逻辑，提高系统的灵活性和可维护性。

##### 2、领域建模与边界上下文划分 #####

电商系统中的聚合和聚合根是什么？

在电商系统中，可以将订单作为一个聚合，其中包括多个领域对象，例如订单项、收货地址、发票信息等。

订单作为一个聚合，它的内部领域对象之间有明确的关联关系，并且需要满足一些业务规则，例如订单项的数量不能为负数，订单状态必须是待付款、待发货、待收货、已完成等状态之一。

在订单聚合中，可以将订单对象作为聚合根，用于保证订单聚合的完整性和一致性。订单对象具有唯一标识和全局访问权限，它可以被其他领域对象引用，例如订单项和收货地址等。

使用聚合和聚合根可以将复杂的业务逻辑封装在一个边界内，提高系统的可维护性和可扩展性。

电商系统是一个涉及到多个业务领域的复杂应用系统，经过上下文建模和边界上下文划分，最后确定电商系统所包含了众多的子域。

以下是电商系统中常见的一些子域：

1.  **商品子域**：包括商品分类、商品管理、商品展示等功能。
2.  **订单子域**：包括下单、订单管理、订单配送、订单支付等功能。
3.  **营销子域**：包括促销活动、优惠券、积分、礼品卡等功能。
4.  **用户子域**：包括用户注册、用户登录、用户个人信息管理等功能。
5.  **支付子域**：包括支付方式、支付渠道、支付接口等功能。
6.  **物流子域**：包括订单配送、物流跟踪、运费计算等功能。
7.  **客服子域**：包括售后服务、用户反馈、在线客服等功能。
8.  **数据统计子域**：包括用户行为分析、交易数据统计、业务数据报表等功能。

在实际的电商应用系统中，可能会根据业务需求进一步细分和扩展各个子域。每个子域都可以作为一个独立的微服务进行设计和开发，从而实现更好的业务解耦和系统扩展性。

#### 第2步：战术阶段 ####

核心是领域服务设计

电商系统中包括的领域服务，主要如下：

1.  **商品服务**：负责管理商品的上架、下架、库存等信息，并提供商品的查询、搜索、推荐等功能。
2.  **订单服务**：负责管理订单的创建、支付、发货、退款等流程，并提供订单的查询、取消、评价等功能。
3.  **用户服务**：负责管理用户的注册、登录、个人信息管理等功能，并提供用户评价、收藏、关注等功能。
4.  **支付服务**：负责管理系统的支付方式、支付账户等信息，并提供支付的流程和接口。
5.  **物流服务**：负责管理物流的配送、快递信息等，并提供物流的查询、跟踪等功能。
6.  **营销服务**：负责管理系统的促销活动、优惠券等信息，并提供优惠券领取、使用等功能。
7.  **数据统计服务**：负责收集、分析、展示系统的数据统计信息，例如订单量、销售额、用户活跃度等。
8.  **客服服务**：负责管理系统的客户服务、投诉处理等工作，并提供在线客服、电话客服等渠道。

这些领域服务之间相互协作，共同实现电商系统的核心功能和业务流程。

通过领域服务的划分和封装，可以提高系统的可扩展性和可维护性，降低系统的耦合度和复杂度。

### 领域驱动设计与微服务的关系 ###

领域驱动设计（DDD）和微服务是两种不同的概念，但它们可以结合在一起来提高软件的质量和可维护性。

微服务架构是一种将应用程序拆分成多个小型、自治的服务的架构模式，每个服务专注于某个特定的业务功能，通过轻量级通信机制进行协作。

微服务架构通常需要处理大量的业务逻辑，因此需要一个清晰的领域模型来管理这些业务逻辑，这时领域驱动设计就能够发挥作用了。

通过领域驱动设计，开发人员可以更好地理解业务需求，更好地建模业务领域，将领域模型作为微服务架构的核心，从而更好地支持微服务架构。

具体来说，领域驱动设计可以帮助实现以下方面：

1.  **微服务的拆分和划分**：通过领域驱动设计，可以将业务领域划分为不同的子域，并将每个子域划分为一个或多个微服务，从而实现微服务的拆分和划分。
2.  **服务间的通信**：微服务架构中的服务需要通过通信机制进行协作。
    
    通过领域驱动设计，可以在微服务之间定义明确的接口和协议，使得服务之间的通信更加清晰和稳定。
3.  **微服务的扩展和维护**：通过领域驱动设计，可以将业务逻辑清晰地划分为不同的领域模型，从而使得微服务的扩展和维护更加容易。例如，在需要修改业务逻辑时，只需要修改对应的领域模型和微服务，而不需要修改整个应用程序。

因此，领域驱动设计可以帮助开发人员更好地支持微服务架构，并实现更好的软件设计和开发。

### 领域驱动设计与敏捷开发相结合 ###

领域驱动设计和敏捷开发是两种不同的方法论，但可以相互结合，提高开发效率和软件质量。

在敏捷开发过程中，团队通常采用迭代式的开发模式，不断地根据用户反馈和需求变化进行调整和优化。

这种敏捷开发模式与领域驱动设计的思想相契合，因为领域驱动设计强调将业务领域建模为一个相对独立的系统，同时也强调不断优化和迭代。

以下是一些结合领域驱动设计和敏捷开发的方法：

1.  **划分迭代周期**：在敏捷开发中，团队通常会划分出多个迭代周期来实现软件的开发和交付。在每个迭代周期中，可以采用领域驱动设计方法进行领域建模和设计，以确保软件系统的质量和可维护性。
2.  **与领域专家和用户紧密合作**：在敏捷开发中，团队需要与领域专家和用户紧密合作，及时获取用户反馈和需求变化。在领域驱动设计中，也需要与领域专家和用户紧密合作，以确保领域建模的准确性和实用性。
3.  **重构和优化**：敏捷开发中，团队需要不断地重构和优化代码，以提高软件系统的质量和可维护性。在领域驱动设计中，也需要不断地优化领域建模和设计，以提高系统的可扩展性和可维护性。
4.  **测试和验收**：在敏捷开发中，团队需要进行测试和验收，以确保软件系统的质量和稳定性。在领域驱动设计中，也需要进行测试和验收，以确保领域建模和设计的准确性和实用性。

### 未完待续，尼恩说在最后 ###

DDD 面试题，是非常常见的面试题。 DDD的学习材料， 汗牛塞屋，又缺乏经典。

大家面试的时候， 可以参考以上的内容去组织答案，如果大家能做到对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

另外在面试之前，建议大家系统化的刷一波 5000页《[尼恩Java面试宝典PDF][Java_PDF]》，并且在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

最终，**让面试官爱到 “不能自已、口水直流”**。offer， 也就来了。

当然，关于DDD，尼恩即将给大家发布一波视频 《第34章：DDD的顶奢面经》， 帮助大家彻底穿透DDD。

![af7035f0220a429b947e9825eae12ba4.png][]

### 尼恩技术圣经系列PDF ###

*  《[NIO圣经：一次穿透NIO、Selector、Epoll底层原理][NIO_NIO_Selector_Epoll]》
 *  《[Docker圣经：大白话说Docker底层原理，6W字实现Docker自由][Docker_Docker_6W_Docker]》
 *  《[K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由][K8S_K8S_14W_K8S]》
 *  《[SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由][SpringCloud Alibaba _10_SpringCloud]》
 *  《[大数据HBase学习圣经：一本书实现HBase学习自由][HBase_HBase]》
 *  《[大数据Flink学习圣经：一本书实现大数据Flink自由][Flink_Flink]》
 *  《[响应式圣经：10W字，实现Spring响应式编程自由][10W_Spring]》
 *  《[Go学习圣经：Go语言实现高并发CRUD业务开发][Go_Go_CRUD]》

……完整版尼恩技术圣经PDF集群，请找尼恩领取

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓

[Java_PDF]: https://blog.csdn.net/crazymakercircle/article/details/132927258
[DDD_0_1_DDD]: https://blog.csdn.net/crazymakercircle/article/details/134128426
[DDD _Repository]: https://blog.csdn.net/crazymakercircle/article/details/134128879
[DDD]: https://blog.csdn.net/crazymakercircle/article/details/134191267
[DDD 1]: https://blog.csdn.net/crazymakercircle/article/details/134221190
[Uber _2200]: https://blog.csdn.net/crazymakercircle/article/details/134341888
[DDD_Interface_Application]: https://blog.csdn.net/crazymakercircle/article/details/134351936
[af7035f0220a429b947e9825eae12ba4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/d21ccf8456f14f0d83ebc573af6c0975.png
[NIO_NIO_Selector_Epoll]: https://blog.csdn.net/crazymakercircle/article/details/133186797
[Docker_Docker_6W_Docker]: https://blog.csdn.net/crazymakercircle/article/details/129482349
[K8S_K8S_14W_K8S]: https://blog.csdn.net/crazymakercircle/article/details/130073643
[SpringCloud Alibaba _10_SpringCloud]: https://blog.csdn.net/crazymakercircle/article/details/129559428
[HBase_HBase]: https://blog.csdn.net/crazymakercircle/article/details/132589856
[Flink_Flink]: https://blog.csdn.net/crazymakercircle/article/details/132347440
[10W_Spring]: https://blog.csdn.net/crazymakercircle/article/details/129022714
[Go_Go_CRUD]: https://blog.csdn.net/crazymakercircle/article/details/131383065