DDD领域驱动（二）——之需求梳理

傷城~ 2023-07-22 09:21 20阅读 0赞

上一篇《[DDD领域驱动（一）——之引入][DDD]》中，我们阐述了中台、微服务、DDD，并从面向对象的基础出发，软件工程的基础出发，简单介绍了DDD，把DDD的知识列了一个框架。让我们对DDD所处于的环境有个清晰的了解，以及其的存在的价值——要解决的问题。好，这篇我们来看一下，需求分析阶段我们通过DDD能做些什么，帮我们从领域角度去梳理需求。好，继续思维导图的细化：

![format_png][]

需求分析，是我们要做一件事最开始要做的，不仅仅适合于软件设计上。其实终极目标就是，梳理明白我们要做什么?为什么要做，要达到什么目标？如何将要做的事情拆分为可落地、可实施的具体小事情（小事情组合成大事情完成）？以及如何大家都达成统一的认知（团队协作）？

--------------------

一，统一语言：

1，交流沟通中的统一语言：在做一件事（中台、微服务、项目），我们往往都是由产品、研发、测试、运维、管理、运营等等一起共同完成的，那么大家在交流中，有必要对一些专有名词理解达成统一。例如，在一些to B系统中，往往会设计：商户（商业角度对接的一个商家）、业务系统（针对不同的业务线的系统）、渠道（带来业务流量的不同入口）、场景（业务的不同展示方式，例如app、wap、pc、公众号）。总结一句话：我们对接了商户X的业务系统一，他们业务流量来源有渠道A，展现方式是H5。看一下图。这样大家在沟通中就没有信息不一致，信息歧异。大大提高沟通效率和准确度。

![format_png 1][]

2，领域中统一语言：其实同一个事物，在不同的环境下，定义也是不一样的。例如：我在公司是员工，在和朋友一起玩的时候是朋友，在领孩子的时候是父亲……这个我觉得比较容易做到，在领域驱动设计，去体现到不同的领域中的时候，展示处理同一个事物的不同属性、方法而已。例如：商品，在库存在中就是货物（货物的相关属性）、交易中是商品（商品的相关属性）、而在物流体系中，又成了快递。

--------------------

二，事件风暴：

其实我最开始接触的是头脑风暴：一群人在正常融洽和不受任何限制的气氛中以会议形式进行讨论、座谈，打破常规，积极思考，畅所欲言，充分发表看法。旨在群策群力。而当学习DDD时，看到类似的词事件风暴，其实就是规定范围，有目标性的头脑风暴，我觉得也可以称其为：群策群力进行通过事件建模。

1，产品愿景（目标）：首先需要明确清晰我们的目标，这个比较虚，但是却非常重要。例如：满足那些人的那些需求、实现什么功能、解决什么问题、达到什么性能、要求多么稳定……；

2，业务场景分析：也就是大家共同，通过事件驱动，来进行梳理需求。说白一点，就是大家一起想下，系统能做什么事？“刷墙”是事件风暴的一种实践方式（类似敏捷开发中的看板），我觉得还好吧，只是一种实践形式，像思维导图、用例图、用户故事等都可以，还可以搭配从不同的角度入手，更好的将事件进行梳理，更清晰的剖析业务。这里看下这几种方式的展示方式，以简单用户系统为例：

刷墙（不同颜色的图片进行分类，方便后期归纳，可根基实际情况而定）：

![format_png 2][]

用例图（从触发事件发生的角度，进行梳理），可以看下《[UML建模专栏][UML]》：

![format_png 3][]

思维导图，就是类似我们大脑思考问题方式，层层展开的方式，大家应该比较熟悉，这里不再提现。

用户故事，则更倾向通过实际业务发生的流程上，进行梳理：

![format_png 4][]

等等，通过各种方式，各种角度，各种切入口，进行需求分析，让其更加清晰明了……

3，领域建模，就是根基业务分析的结果，划分边界，抽象领域、实体、值对象、领域服务、领域事件、聚合等，方便后边的代码的落地；

4，微服务拆分与设计：根据领域建模的成果，进行领域划分，界限上下文边界，以及领域内的分层、抽象、归纳聚合等。达到最终可以实施的方案。

--------------------

三，问题领域分析划分，就是自定向下，逐级拆解，将复杂的业务一步步拆分，单元越来越小，越来越高内聚，越来越简单可实施：

1，第一重拆分：抽象子领域，DDD分为：核心子领域、通用子领域、支撑子领域。其实用户系统已经可以当做一个用户管理子域，在业务中可以充当支撑子领域角色……

2，第二重拆分：限界上下文，将子域进行划分，例如用户管理管理子域，可以划分为权限上下文、机构上下文、用户上下文等

3，第三重拆分：逻辑分层，例如将用户登录，划分为：接口层、应用层、领域服务层、基础调用层。从纵向的角度，将一个服务的实现，进行解耦。

4，第四重拆分：聚合，划分最小单元，例如：用户聚合、机构聚合、权限聚合……最小维度的单位，达成高内聚的服务能力单元。

--------------------

四，业务建模需求分析，也就是通过不同方式进行需求分析，我们通过不同角度，不同方式，不同切入口……能够更加清晰的掌握需求。那句话怎么说“盲人摸象”，只有我们通过不同角度的进行分析，学习，才能够真正的理解业务本质。

--------------------

总而言之，无论什么思想，做事第一步都需要我们进行分析，做项目第一步，都需要进行需求分析，只有充分明白了需求，更多的理解了需求分来世今生，才能设计编写出高内聚、低耦合，灵活易扩展额程序……而，通过大家一起进行分析，又能使大家达到统一的认知水平，信息一致，大大提高后期的沟通协作效率。好，今天先这样吧……

[DDD]: https://blog.csdn.net/liujiahan629629/article/details/105303263
[format_png]: /images/20230528/5f4276ff27a248f28ee1a4b90306673a.png
[format_png 1]: /images/20230528/0739c2bb5f984bcda1b1406c65c3e63e.png
[format_png 2]: /images/20230528/b723a7091a264c139afdbcb545b45471.png
[UML]: https://blog.csdn.net/liujiahan629629/category_1270121.html
[format_png 3]: /images/20230528/edd3293eb8fc4aebb7d8a25f905247a6.png
[format_png 4]: /images/20230528/c6b6b40b30e44860809b923a04a0b49e.png