领域驱动应对业务复杂度

之前的文章提到过，领域驱动设计分成战略层次和战术层次，战略层次我们讨论的很多了，接下来我们主要看下战术层次要搞哪些事情，以及领域驱动如何以架构的形式落地呢。

分层架构

在进行软件系统架构过程中，分层架构是首先会想到的一种架构方式，主要按照职责进行横向划分。

CQRS

这个是我们在通过领域驱动进行架构设计首先想到的一种普世的架构，读写分离，读方向和写方向的的系统瓶颈可以针对性的进行解决和优化。

其核心思想如下：

Command：不返回结果，但会改变对象状态
Query：返回结果，但是不会改变对象的状态，多次查询对于系统没有其他影响

六边形架构

六边形架构的提出主要是对标分层架构，原有的分层架构可以通过水平方式进行逻辑内聚，但是在同一个平层内其实没有起到隔离的效果，于是就有人提出了六边形架构，也就是提出了“内部”和“外部”的概念。

“内部”能力主要是代表了业务逻辑，“外部”表示应用的驱动逻辑，基础设施及其他应用。后续有人在六边形的六个方向上分别定义了不同的“外部”能力，如：

Rest API
MQ
RPC
ES Search
ORM 等。

洋葱圈架构

洋葱圈和六边形架构很类似，背后的思想都是保护核心业务逻辑，不受其他设施迭代而影响（业务和非业务的一种分离），非业务逻辑采用适配器方式进行解耦，避免渗透到核心业务中，这样实现了设施替换而业务无感知的效果，业务和设施迭代互不影响。

外层依赖于内层
内层对外层无感知

在洋葱头和领域驱动叠加之后，可以变成一个分层的洋葱头：

Application -> Domain Service -> Domain Model -> Infrastructure

整洁架构

整洁架构是对三层架构的一种改良，将三层中的业务逻辑层进一步拆分成应用层，领域层，基础设施层。

类似于：

API层：同程负责RestAPI的web请求，将请求交给逻辑层执行，并返回视图模型viewModel
逻辑层：获取请求输入，组装上下文，输入校验，调用领域服务编排，还可以在这层衔接基础设施，比如MQ做异步调用
领域层：封装了核心的业务逻辑，通过Domain Service和Entities的开放还是对外提供业务逻辑
持久层：承接各种数据源，比如MySql，NoSql，搜索引擎，文件系统等服务

领域驱动解决扩展能力

在简单的业务场景，系统对于扩展性的要求并不高，于是很多程序员对于扩展能力的训练就少一些。但是随着业务发展的越来越快，复杂度逐渐增高，代码中可能通过大量的if-else进行逻辑处理，在架构层面有没有好的应对扩展性的解决方案呢？

以业界流行的中台解决方案（阿里的TMF）来说，一般存在两个很重要的概念：

业务身份
扩展点

业务身份（BizCode）

指的是业务在系统中的唯一标识一个业务或者一个场景的标记，BizCode可以采用类似于Java包命名空间的方式命名，如“ali.tmall”表示的是天猫。

扩展点（ExtensionPoint）

每个业务或者场景都可以实现一个或多个扩展点，业务身份加上扩展点，可以唯一的确定一个扩展实现（Extension）。

有了业务身份和扩展点，可以从框架或者平台纬度实现多租户的管理。不同业务，不同场景都可以实现定制。阿里的中台主要也是围绕于这个思想，实现了一个平台框架的多业务支撑。

约定大于配置

最开始使用MVC架构时，听到过“约定大于配置”这句话，意思是将规则性的东西固化下来，尽量减少随心所欲而带来的复杂度。

我们可以在系统中针对于架构命名，模块命名，规范约束，组件，包等进行命名，实现标准化和约束性，以提高系统的可维护性。

网上找了一个基于DDD和CQRS的架构，通过使用扩展点和元数据提供了系统的扩展性：

总结

不管是分层架构，六边形架构，还是洋葱圈架构，还是整洁架构，我们可以发下一个共同点，就是“核心业务逻辑与技术细节分离”，我们在网关拆分上也是基于这一点做的，核心业务下沉，网关只维护技术相关细节。

核心业务逻辑下沉之后，可以实现领域模型和领域服务的复用，没有技术细节的代码也更易于RD所理解。技术细节不受业务迭代限制，随时可以升级或是丢弃。