DDD领域驱动(二)——之需求梳理

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

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


        一,统一语言:

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

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


         二,事件风暴:

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

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

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

         刷墙(不同颜色的图片进行分类,方便后期归纳,可根基实际情况而定):

       用例图(从触发事件发生的角度,进行梳理),可以看下《UML建模专栏》:

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

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

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

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

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


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

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

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

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

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


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


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

猜你喜欢

转载自blog.csdn.net/liujiahan629629/article/details/105326181
今日推荐