本文主要是介绍【领域驱动设计 打通DDD最小闭环】DDD的开发流程、参与人员和统一语言，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
第一个学习阶段就是夯实基础，打通DDD的一个最小闭环，首先明确下DDD的最小闭环包含哪些步骤
开发流程
DDD的整体开发流程如下图所示，包含两个大的时间节点，模型的建立和模型的实现。
这样就是一个DDD的最小闭环，在实践中，尤其是对敏捷软件开发来说，这些步骤不是线性的，而是反复迭代、互相穿插的
战略设计阶段
也就是模型的建立阶段，使用的都是业务术语，归根结底来自业务人员，业务人员不仅能听懂，而且负责评价建模的正确性，所以必须由技术人员+业务人员共同主导
1 需求分析
在整个开发流程中，首先是要捕获行为需求，也就是传统软件工程里的“获取需求”。这一步，我们要识别需求里有哪些流程、哪些功能，每个功能由什么人操作，会产生什么结果，我们使用的分析方式是：业务事件风暴
2 领域建模
需求捕获完成后，接下来，我们就可以进行领域建模了，也就是通过建立领域模型，把需求里的主要业务知识描述清楚
战术设计阶段
也就是模型的实现阶段，业务人员不需要理解也不关注的，会包含技术实现方面的内容，所以由技术人员主导
3 架构设计
基于领域模型，我们就可以做架构设计，包括进程间和进程内的架构。比如说
- 进程间架构：微服务设计、中台设计都属于进程间架构。
- 进程内架构：通常说的 DDD 分层架构是进程内架构
对于项目实践来说，其实进程间可以理解为服务间的交互方式，进程内指的是服务内各个模块的交互方式。
4 数据库设计
依据架构设计进行对应的数据库表设计
5 代码实现
最后一步是按照设计完成代码编写。从这里也可以看的出来，代码实现其实是最容易的，一旦整体的设计成型了，代码实现就是水到渠成的事情，把文本语言翻译成计算机语言的过程。
参与人员
参与人员分为业务方和技术方，对于不同的业务，角色是不一定的
- 领域专家：领域专家需要对业务有总体性和本质性的把握，同时对业务发展也要有一定前瞻性，对于商户可能就是：业务策略、商业分析师、运营、PA、PM等各种角色
- 架构师及核心开发人员：要懂一些业务基础概念能够和业务讨论，了解相关业务模式，技术上一定要过硬。
核心就是这两方，不同阶段可能会有所补充，例如实现阶段可能会有一些基础RD、QA、FE等角色参与进来。
统一语言
在设计前一定要通过事件风暴形成UL语言表，确保大家对一件事物的理解是一致的，提到这个名词对它背后的含义和本质信息有共识，如果前期认知有GAP，后期实现阶段问题会被放大很多。
总结一下
其实我们日常开发都比较伪DDD，整体实现还是使用 MVC，代码结构类似 Controller、Service、DAO，个人认为这也无可厚非，只是代码的组织形式而已，关键是我们在整体设计时往往缺乏（领域建模-架构设计）这关键两步，很多时候都是就着一个功能点进行（需求分析-数据库 -> 代码实现）。这样没有全局的视角很容易盲人摸象，导致后续摸到一点打个补丁，项目难以维护。DDD的关键不全然是代码架构设计的指导，更是一种应对复杂业务的开发及协作模式，关键人员先通过UL建立有全局共识认知，不确认的地方预留扩展点，再进行穿插迭代式的小闭环补足认知和功能偏差更好些。
这篇关于【领域驱动设计 打通DDD最小闭环】DDD的开发流程、参与人员和统一语言的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
