之前的文章提到过,领域驱动设计分成战略层次和战术层次,战略层次我们讨论的很多了,接下来我们主要看下战术层次要搞哪些事情,以及领域驱动如何以架构的形式落地呢。
分层架构
在进行软件系统架构过程中,分层架构是首先会想到的一种架构方式,主要按照职责进行横向划分。
CQRS
这个是我们在通过领域驱动进行架构设计首先想到的一种普世的架构,读写分离,读方向和写方向的的系统瓶颈可以针对性的进行解决和优化。
其核心思想如下:
六边形架构
六边形架构的提出主要是对标分层架构,原有的分层架构可以通过水平方式进行逻辑内聚,但是在同一个平层内其实没有起到隔离的效果,于是就有人提出了六边形架构,也就是提出了“内部”和“外部”的概念。
“内部”能力主要是代表了业务逻辑,“外部”表示应用的驱动逻辑,基础设施及其他应用。后续有人在六边形的六个方向上分别定义了不同的“外部”能力,如:
洋葱圈架构
洋葱圈和六边形架构很类似,背后的思想都是保护核心业务逻辑,不受其他设施迭代而影响(业务和非业务的一种分离),非业务逻辑采用适配器方式进行解耦,避免渗透到核心业务中,这样实现了设施替换而业务无感知的效果,业务和设施迭代互不影响。
在洋葱头和领域驱动叠加之后,可以变成一个分层的洋葱头:
Application -> Domain Service -> Domain Model -> Infrastructure
整洁架构
整洁架构是对三层架构的一种改良,将三层中的业务逻辑层进一步拆分成应用层,领域层,基础设施层。
类似于:
在简单的业务场景,系统对于扩展性的要求并不高,于是很多程序员对于扩展能力的训练就少一些。但是随着业务发展的越来越快,复杂度逐渐增高,代码中可能通过大量的if-else进行逻辑处理,在架构层面有没有好的应对扩展性的解决方案呢?
以业界流行的中台解决方案(阿里的TMF)来说,一般存在两个很重要的概念:
业务身份(BizCode)
指的是业务在系统中的唯一标识一个业务或者一个场景的标记,BizCode可以采用类似于Java包命名空间的方式命名,如“ali.tmall”表示的是天猫。
扩展点(ExtensionPoint)
每个业务或者场景都可以实现一个或多个扩展点,业务身份加上扩展点,可以唯一的确定一个扩展实现(Extension)。
有了业务身份和扩展点,可以从框架或者平台纬度实现多租户的管理。不同业务,不同场景都可以实现定制。阿里的中台主要也是围绕于这个思想,实现了一个平台框架的多业务支撑。
最开始使用MVC架构时,听到过“约定大于配置”这句话,意思是将规则性的东西固化下来,尽量减少随心所欲而带来的复杂度。
我们可以在系统中针对于架构命名,模块命名,规范约束,组件,包等进行命名,实现标准化和约束性,以提高系统的可维护性。
网上找了一个基于DDD和CQRS的架构,通过使用扩展点和元数据提供了系统的扩展性:
不管是分层架构,六边形架构,还是洋葱圈架构,还是整洁架构,我们可以发下一个共同点,就是“核心业务逻辑与技术细节分离”,我们在网关拆分上也是基于这一点做的,核心业务下沉,网关只维护技术相关细节。
核心业务逻辑下沉之后,可以实现领域模型和领域服务的复用,没有技术细节的代码也更易于RD所理解。技术细节不受业务迭代限制,随时可以升级或是丢弃。