分布式架构设计原则:领域驱动设计与业务驱动划分

写在前面:

  •     你好,欢迎你的阅读!
  •     我热爱技术,热爱分享,热爱生活, 我始终相信:技术是开源的,知识是共享的!
  •     博客里面的内容大部分均为原创,是自己日常的学习记录和总结,便于自己在后面的时间里回顾,当然也是希望可以分享自己的知识。目前的内容几乎是基础知识和技术入门,如果你觉得还可以的话不妨关注一下,我们共同进步!
  •     除了分享博客之外,也喜欢看书,写一点日常杂文和心情分享,如果你感兴趣,也可以关注关注!
  •     微信公众号:傲骄鹿先生

领域驱动设计(Domain-Driven Design,DDD )是由Eric Evans最先提出,目的是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题。整个过程大概是这样的,开发团队和领域专家一起通过 通用语言(Ubiquitous Language)去理解和消化领域知识,从领域知识中提取和划分为一个一个的子领域(核心子域,通用子域,支撑子域),并在子领域上建立模型,再重复以上步骤,这样周而复始,构建出一套符合当前领域的模型。与现在的分布式、微服务相比,绝对是即将步入中年的“老家伙”了。直到近些年微服务理论被提出、被互联网行业广泛使用,人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务,领域驱动设计才迎来了第二春。

一、关于DDD

什么是DDD,“DDD是一种可以借鉴的思想,而非严格遵循的方法论”。

学习领域驱动设计的意义在于:

  • 一套完整的模型驱动的软件设计方法,用于简化软件项目的复杂度,它能带给你从战略设计到战术设计的规范过程,使得你的设计思路能够更加清晰,设计过程更加规范;
  • 一种思维方式和概念,可以应用在处理复杂业务的软件项目中,加快项目的交付速度;
  • 一组提炼出来的原则和模式,可以帮助开发者开发优雅的软件系统、促进开发者对架构与模型的精心打磨,尤其善于处理系统架构的演进设计、有助于提高团队成员的面向对象设计能力与架构设计能力;
  • 领域驱动设计与微服务架构天生匹配,无论是在新项目中设计微服务架构,还是将系统从单体架构演进到微服务设计,都可以遵循领域驱动设计的架构原则。

1、什么是领域/子领域(Domain/Subdomain)

领域是与某个特定问题相关的知识和行为。比如支付平台就属于特定的领域,只要是这个领域,都会有账户、会记、收款、付款、风控等核心环节。所以,同一个领域的系统都具有相同的核心业务,他们要解决的问题的本质是一致的。一个领域本质上可以理解为就是一个问题域,只要是同一个领域,那问题域就相同。所以,只要我们确定了系统所属的领域,那这个系统的核心业务,即要解决的关键问题、问题的范围边界就基本确定了。

在日常开发中,我们通常会将一个大型的软件系统拆分成若干个子系统。这种划分有可能是基于架构方面的考虑,也有可能是基于基础设施的。在DDD中,我们对系统的划分是基于领域(基于业务)的。比如上文提到支付平台是一个领域,而账户、会记、收款、付款等则为子领域。一个领域由众多子领域聚集而形成。

在一个领域/子域中,我们会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义。这样的边界便称为限界上下文。限界上下文和领域具有一对一的关系。从物理层面讲,一个限界上下文最终可以是一个Jar/War文件,甚至可以是一个Package中的所有对象。但是,技术本身并不是用来界分限界上下文。

2、设计(Design)和驱动(Driven)

DDD中的设计主要指领域模型的设计。DDD是一种基于模型驱动开发的软件开发思想,强调领域模型是整个系统的核心,领域模型也是整个平台的核心价值。每一个领域都有一个对应的领域模型,领域模型能够很好的解决负责的业务问题。所以领域模型的设计和架构设计同等重要。

DDD中,总是以领域为边界,分析领域中的核心问题(核心关注点)。然后设计对应的领域模型,通过领域模型驱动代码的实现。而数据库设计、持久化技术这些都不是DDD的核心,属于外围的东西。与数据库驱动开发的思路形成对比,驱动中需要记住两个原则:领域驱动领域模型设计,领域模型驱动代码实现。

3、领域驱动设计中的领域模型

回想日常的开发过程,日常建表,然后写CRUD,因此也有一句很真实的话“面试造火箭,工作拧螺丝”。其根本原因在于表驱动思想,而不是领域驱动设计。

前者只能增加数据库的表数量,而后者才会形成长期的、具有业务意义的模型,这样的系统生命力才更加长久。我们也才能用工程的方法来编码,从编码转身为业务域的开发专家。有很多关于领域驱动设计的论述中都并未明确我们如何得到“领域”,只有合理的领域模型才能有效驱动设计开发。所以建好领域模型是关键,对于领域模型的思考与技术框架升级同样重要。

4、从分层架构到六边形架构

4.1 分层架构

分层架构是运用最为广泛的架构模式,几乎每个软件系统都需要通过层来隔离不同的关注点,以此应对不同需求的变化,使得这种变化可以独立进行;各个层、甚至同一层中的各个组件都会以不同速率发生变化。

这里所谓的“以不同速率发生变化”,其实就是引起变化的原因各有不同,这正好是单一职责原则(Single-Responsibility Principle,SRP)的体现。即“一个类应该只有一个引起它变化的原因”,换言之,如果有两个引起类变化的原因,就需要分离。

单一职责原则可以理解为架构原则,这时要考虑的就不是类,而是层次。例如网络七层协议是一个定义的非常好的、经典的分层架构,简单、易于学习理解,最终被广泛使用进而大大推动了网络通信的发展。

通常情况下,我们会把软件系统分为这几个层:UI界面(或者接入层)、应用独有的业务逻辑、领域普适的业务逻辑、数据库等。

接下来,还有什么不同原因的变更呢?答案正是这些业务逻辑本身!在每一层内部,不同的业务场景发生变化的原因、频次也都不同,不同的场景我们分别定义为业务用例。由此,我们可以总结出一个模式:在将系统水平切分成多个分层的同时,按用例将其切分成多个垂直切片。这样做的好处就是对单个用例的修改并不会影响其他用例。

如果我们同时对支持这些用例的UI和数据库也进行了分组,那么每个用例使用各自的UI表现与数据库,这样就做到了自上而下的解耦。另一方面,有层次就有依赖。在OSI协议中,上层透明的依赖下层。但是在软件架构中,我们更强调“依赖抽象”。即组件A依赖B的功能,我们的做法是在A中定义其需要用到的接口,由B去实现对应接口能力,这样就做到了可插拔,将来我们可以把B替换为同样实现了接口能力的组件C而对系统不会造成影响。

4.2 整洁架构

分层架构中给人的感觉是每一层都同样重要,但如果我们把关注的重点放在领域层,同时把依赖关系按照业务由重到轻形成一个以领域层为中心的环,即演变为一种整洁的架构风格。这里不是说其他层不重要,仅仅是为了凸显承载了业务核心的领域能力。

整洁架构最主要原则是依赖原则,它定义了各层的依赖关系,越往里,依赖越低,代码级别越高。外圆代码依赖只能指向内圆,内圆不知道外圆的任何事情。一般来说,外圆的声明(包括方法、类、变量)不能被内圆引用。同样的,外圆使用的数据格式也不能被内圆使用。

整洁架构各层主要职能如下:

  • Entities:实现领域内核心业务逻辑,它封装了企业级的业务规则。一个 Entity 可以是一个带方法的对象,也可以是一个数据结构和方法集合。一般我们建议创建充血模型。

  • Use Cases:实现与用户操作相关的服务组合与编排,它包含了应用特有的业务规则,封装和实现了系统的所有用例。

  • Interface Adapters:它把适用于 Use Cases 和 entities 的数据转换为适用于外部服务的格式,或把外部的数据格式转换为适用于 Use Casess 和 entities 的格式。

  • Frameworks and Drivers:这是实现所有前端业务细节的地方,UI,Tools,Frameworks 等以及数据库等基础设施。

4.3 六边形架构

我们把整洁架构的外部依赖按照其输入输出功能、资源类型进行整合。将存储、中间件、与其他系统的集成、http调用分别暴露一个端口。则会演变成下面的架构图。

系统能平等地被用户、其他程序、自动化测试或脚本驱动,也可以独立于其最终的运行时设备和数据库进行开发和测试”这是六边形的精髓。

该架构由端口和适配器组成,所谓端口是应用的入口和出口,在许多语言中,它以接口的形式存在。例如以取消订单为例,“发送订单取消通知”可以被认为是一个出口端口,订单取消的业务逻辑决定了何时调用该端口,订单信息决定了端口的输入,而端口为上游的订单相关业务屏蔽了其实现细节。

而适配器分为两种,主适配器(别名Driving Adapter)代表用户如何使用应用,从技术上来说,它们接收用户输入,调用端口并返回输出。Rest API是目前最常见的应用使用方式,以取消订单为例,该适配器实现Rest API的Endpoint,并调用入口端口OrderService,当然service内部可能发送OrderCancelled事件。同一个端口可能被多种适配器调用,本场景的取消订单也可能会被实现消息协议的Driving Adapter调用以便异步取消订单。

次适配器(别名Driven Adapter)实现应用的出口端口,向外部工具执行操作,例如向MySQL执行SQL,存储订单;使用Elasticsearch的API搜索产品;使用邮件/短信发送订单取消通知。有别于传统的分层形象,形成一个六边形,因此也会称作六边形架构。

二、如何DDD

1、界限上下文

领域中还同时存在问题空间(problem space)和解决方案空间(solution space)。在问题空间中,我们思考的是业务所面临的挑战,而在解决方案空间中,我们思考如何实现软件以解决这些业务挑战。

  • 问题空间是领域的一部分,对问题空间的开发将产生一个新的核心域。对问题空间的评估应该同时考虑已有子域和额外所需子域。因此,问题空间是核心域和其他子域的组合。问题空间中的子域通常随着项目的不同而不同,他们各自关注于当前的业务问题,这使得子域对于问题空间的评估非常有用。子域允许我们快速地浏览领域中的各个方面,这些方面对于解决特定的问题是必要的。
  • 解决方案空间包含一个或多个界限上下文,即一组特定的软件模型。这是因为界限上下文是一个特定的解决方案,用以解决问题。

通常,我们希望将子域一对一地对应到限界上下文。这种做法显式地将领域模型分离到不同的业务板块中,并将问题空间和解决方案空间融合在一起。

但是在实践中,这种做法并不总是可能的,想像一下,谁没有维护过“毛线团”系统,现在我们就要借助界限上下文来安全的、合理的、快速的理顺这堆交织不清的关系。

 

电子商务系统是个典型的“大线团”,我们按照经验将其在逻辑上拆解为:产品目录子域、订单子域、发票子域,当然你也可以拆解出更多的子域,甚至将产品目录子域继续向下分解为类目子域、商品子域(虚线是逻辑子域)。另外还有一个专门用于库存管理的库存系统、以及用于销售预测的预测系统。

电商系统里面也存在物流相关的业务逻辑,同时物流又不可避免的作用于库存逻辑之上。而往往最难以把握的就是这部分相交的地方,这才是实际的项目场景,我们通常做法是将其归并为一个新的履约系统,作为一个支撑子域去辅助主要的电商系统。

当然,随着业务不断发展,我们的履约模式(比如支持同城当日达、商家仓储发货、电商集货仓发货、退货等等)、库存类型(调拨库存、越库操作、临期库存、残次库存等等)越来越复杂,我们考虑将其再向下分解为履约系统2.0、库存系统2.0。

核心就是我们可以在概念上使用多个子域来分解较大的界限上下文,也可以将多个分散的界限上下文包含在同一个新的子域当中,最终做到“子域和界限上下文一一对应”。我个人觉得,这个过程是最考验内功心法的地方。

上面我们已经说了会拆解出来新的子域,目的使“整洁干净”的界限上下文能够一对一的解决这个子域对应的问题空间,但是随着拆解就必然导致“关联关系”。因为要解决问题空间,必须使用对应的子域,你可以把它拆解出去,但是它始终存在于依赖网中。

我们通用的做法是在相交的地方,定义接口。由支撑的界限上下文去实现,可以做到支撑上下文的插拔式切换。这里仍然是我们强调的“依赖抽象”“解耦”。

2、Repository

“对于每种需要进行全局访问的对象,我们都应该创建另一个对象来作为这些对象的提供方,就像是在内存中访问这些对象的集合一样。为这些对象创建一个全局接口以供客户端访问。为这些对象创建添加和删除方法……

此外,我们还应该提供能够按照某种指定条件来查询这些对象的方法……只为聚合创建资源库”引用自《领域驱动设计》。大家和我的疑问一样,Repository是什么?DAO与Repository什么区别?为什么需要Repository?

首先,Repository 是一个独立的层,介于领域层与数据映射层(数据访问层)之间。

它的存在让领域层感觉不到数据访问层的存在,它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository 是仓库管理员,领域层需要什么东西只需告诉仓库管理员,由仓库管理员把东西拿给它,并不需要知道东西实际放在哪。其核心还是“解耦”,所以我们应该明确领域层只应该使用Repository获取对象。

接下来,看看DAO与Repository什么区别。

我的理解是这样,你可以将Repository当作 DAO 来看待,但是请注意一点,在设计Repository时,我们应该采用面向集合的方式,而不是面向数据访问的方式。这有助于你将自己的领域当作模型来看待,而不是 CRUD 操作;Repository是面向领域的,Repository定义的目的不是DB驱动的,Repository管理的数据的最小粒度是聚合根,这两点和DAO有很大不同。

通常我们建议把Repository定义为一个集合并且只提供类似集合的接口,比如Add,Remove,Get这种操作。一言以蔽之,我们要用集合的思想来操作聚合根,而不是传统的面向DB的CRUD方法。

后来看看为什么需要Repository,我理解还是“解耦”。当我们把Repository想象成一个资源库,也不关心背后的持久化,这些也不是DDD该思考的东西,我们可以用mysql来实现,也可以用mongo,甚至redis。尤其是当我们在更换底层存储时候,领域层以及相关的服务并无任何影响。

三、总结

那么微服务和DDD是什么关系呢?其实在2015年的一次演讲中,DDD的提出者Eric Evans表达了对微服务技术的热爱与支持,认为微服务是让DDD落地的好工具。因为DDD和微服务其本质是降低软件项目的复杂性,而DDD是一种设计理念/设计方法,DDD需要有强制性的原则做保障,否则不同的领域对象终究会混在一起。而微服务本身的一些限制,以及大家都能理解微服务的实施前提和首要条件,会在实现上给DDD增加了一些原则限制。DDD和微服务的不一定要同时使用落地,但是如果将DDD和微服务结合一起,效果是非常不错的。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

傲骄鹿先生

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值