DDD是什么?

领域驱动设计是一种处理高度复杂域的设计方法,试图分离技术实现的复杂性,围绕业务概念构建领域模型来控制业务的复杂性,以解决软件难以理解,难以演化等问题。团队应用它可以成功地开发复杂业务软件系统,使系统在演进时任然保持敏捷。

另外一种解读:DDD不是语言,不是框架,不是架构,而是一种思想,一种套路,它可以分离业务复杂度和技术复杂度,DDD也并不是一个新的事物,它是面向对象的拔高,最终目标还是

高内聚,底耦合

DDD主要解决的问题?

  1. 如何合理的划分业务系统?
    这为微服务的划分提供了方法论(微服务的粒度的问题,多大算大,多小又算小,在微服务刚兴起时,很多企业或者架构师对它都没有统一且明确的定义,这里给些examples,e.g:代码行数?职责的划分?披萨原则?组织结构?)界限上下文很好的回答了这个问题,这也是DDD最近几年借微服务的东风,火起来的原因之一(领域驱动设计的提出距今已经十多年,但真正火热起来大约是在2013年微服务架构被提出来之后)。

  2. 如何保持业务架构和系统架构的一致性?
    与传统的系统相比,DDD里面强调领域专家和技术团队的合作,建立统一语言“普通话”, 聚焦在领域,领域逻辑和业务流程上面,使整体团队对同一个业务术语有统一的认识,避免理解的偏差,并将这些“术语”映射到代码中,随着系统的演进变迁。

DDD战略设计?

DDD领域划分?

根据问题域,将问题划分为Core domain,Sub domain, Support subdomain和generic subdomian,大概标准如下:

核心域:核心竞争力,核心业务 (需要投入最好的人力和资源)
支持子域: 没有,很糟糕; 有,也不足以脱颖而出(可以考虑外包)
通用子域:都有的东西, 比如认证, 发短信, 客服系统等(可以考虑购买商业解决方案或者采用开源方案)

DDD领域建模方法?

领域建模的方式很多种,比如四色建模、OOAD还有事件风暴,我们这里只简单聊聊如何使用事件风暴梳理业务流程,建立领域模型,划分边界。

DDD事件风暴四部曲?

  1. 识别领域事件
    事件是对结果进行建模,我们在寻找领域事件时,首先需要明白领域事件具备的几个特征:

具有业务意义
过去时,e.g: “XX已XX”
时序性
事件风暴以过去发生的事件追溯系统的数据和行为,从而进行合适的建模,e.g:

事件风暴.png

  1. 识别命令
    命令可以理解为不同角色用户在界面上面的操作,比如“添加商品”,“编辑库存”,“提交订单”等; 有些命令可能产生多个事件,可以将他们用箭头联系起来; 在进行这个过程中,我们也需要将角色,通过不同的颜色标示出来 e.g:
    命令风暴.png

  2. 寻找聚合
    在DDD中,聚合是一组相关的领域对象,其目的是要确保业务规则在边界内的不变性,聚合根具有全局标识,所有对聚合根内对象的修改,都只能通过聚合根进行,聚合帮助我们简化了复杂的对象网络,逐步做到“高内聚,低耦合”。
    在识别聚合的时候,我们可以通过对命令和事件的划分找到聚合边界,识别出分布在时间轴上面不同位置的相关命令和事件,e.g:
    寻找聚合.png

  3. 边界划分
    划分服务的边界,它一定程度上面对应的是“界限上下文”,关于它有一个非常形象的定义:
    细胞之所以会存在,是因为细胞膜定义了什么在细胞内,什么在细胞外,并且确定了什么物质可以通过细胞膜

一个聚合可能是最小颗粒度的界限上下文,同时,我们常合并业务相关性很高的聚合。e.g:

界限上下文.png

最后在领域划分的时候,需要团队一起对业务达成共识,首先建立统一语言,然后识别领域模型,划分子域和界限上下文,在验证界限上下文的时候,如果你发现有过多的角色在同一个子域或者界限上下文时,就需要注意了,这就是典型的坏味道,需要及时调整的讯号。

DDD与微服务

理想情况下,界限上下文与微服务可以一一对应,在实际项目中,有些调整,比如根据业务的相关度和变化频率,有时候我们会将多个界限上下文进行合并;另外微服务在开发,测试,部署,发布和运维等等时,相比单体应用而言,它面临了所有分布式系统面临的问题,带来了额外的复杂度和开销,所以将微服务粒度拆分过细反而是一种反模式,需要考虑需要解决问题的复杂度,将相对简单的服务合并在一起;在微服务拆分的时候,也要注意:“聚合是服务的最小单元”(一个界限上下文可以包括多个聚合),打破聚合,就很有可能破坏事务一致性和业务约束。

参考资料