分层架构、六边形架构、CQRS架构模式解读

DDD

DDD&＃xff08;Domain Driven Design&＃xff0c;领域驱动设计&＃xff09;作为一种软件开发方法&＃xff0c;它可以帮助我们设计高质量的软件模型。在正确实现的情况下&＃xff0c;我们通过DDD完成的设计恰恰就是软件的工作方式。
UL&＃xff08;Ubiquitous Language&＃xff0c;通用语言&＃xff09;是团队共享的语言&＃xff0c;是DDD中最具威力的特性之一。不管你在团队中的角色如何&＃xff0c;只要你是团队的一员&＃xff0c;你都将使用UL。由于UL的重要性&＃xff0c;所以需要让每个概念在各自的上下文中是清晰无歧义的&＃xff0c;于是DDD在战略设计上提出了模式BC&＃xff08;Bounded Context&＃xff0c;限界上下文&＃xff09;。UL和BC同时构成了DDD的两大支柱&＃xff0c;并且它们是相辅相成的&＃xff0c;即UL都有其确定的上下文含义&＃xff0c;而BC中的每个概念都有唯一的含义。
一个业务领域划分成若干个BC&＃xff0c;它们之间通过Context Map进行集成。BC是一个显式的边界&＃xff0c;领域模型便存在于这个边界之内。领域模型是关于某个特定业务领域的软件模型。通常&＃xff0c;领域模型通过对象模型来实现&＃xff0c;这些对象同时包含了数据和行为&＃xff0c;并且表达了准确的业务含义。
从广义上来讲&＃xff0c;领域即是一个组织所做的事情以及其中所包含的一切&＃xff0c;表示整个业务系统。由于“领域模型”包含了“领域”这个词&＃xff0c;我们可能会认为应该为整个业务系统创建一个单一的、内聚的和全功能式的模型。然而&＃xff0c;这并不是我们使用DDD的目标。正好相反&＃xff0c;领域模型存在于BC内。

在微服务架构实践中&＃xff0c;人们大量地使用了DDD中的概念和技术&＃xff1a;

1. 微服务中应该首先建立UL&＃xff0c;然后再讨论领域模型。
2. 一个微服务最大不要超过一个BC&＃xff0c;否则微服务内会存在有歧义的领域概念。
3. 一个微服务最小不要小于一个聚合&＃xff0c;否则会引入分布式事务的复杂度。
4. 微服务的划分过程类似于BC的划分过程&＃xff0c;每个微服务都有一个领域模型。
5. 微服务间的集成可以通过Context Map来完成&＃xff0c;比如ACL&＃xff08;Anticorruption Layer&＃xff0c;防腐层&＃xff09;。
6. 微服务间最好采用Domain Event&＃xff08;领域事件&＃xff09;来进行交互&＃xff0c;使得微服务可以保持松耦合。

分层架构

分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。分层架构可以简单分为两种&＃xff0c;即严格分层架构和松散分层架构。在严格分层架构中&＃xff0c;某层只能与位于其直接下方的层发生耦合&＃xff0c;而在松散分层架构中&＃xff0c;则允许某层与它的任意下方层发生耦合。

分层架构的好处是显而易见的。首先&＃xff0c;由于层间松散的耦合关系&＃xff0c;使得我们可以专注于本层的设计&＃xff0c;而不必关心其他层的设计&＃xff0c;也不必担心自己的设计会影响其它层&＃xff0c;对提高软件质量大有裨益。其次&＃xff0c;分层架构使得程序结构清晰&＃xff0c;升级和维护都变得十分容易&＃xff0c;更改某层的具体实现代码&＃xff0c;只要本层的接口保持稳定&＃xff0c;其他层可以不必修改。即使本层的接口发生变化&＃xff0c;也只影响相邻的上层&＃xff0c;修改工作量小且错误可以控制&＃xff0c;不会带来意外的风险。
要保持程序分层架构的优点&＃xff0c;就必须坚持层间的松散耦合关系。设计程序时&＃xff0c;应先划分出可能的层次&＃xff0c;以及此层次提供的接口和需要的接口。设计某层时&＃xff0c;应尽量保持层间的隔离&＃xff0c;仅使用下层提供的接口。
关于分层架构的优点&＃xff0c;Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案&＃xff1a;

1. 开发人员可以只关注整个结构中的某一层。
2. 可以很容易的用新的实现来替换原有层次的实现。
3. 可以降低层与层之间的依赖。
4. 有利于标准化。
5. 利于各层逻辑的复用。

“金无足赤&＃xff0c;人无完人”&＃xff0c;分层架构也不可避免具有一些缺陷&＃xff1a;

1. 降低了系统的性能。这是显然的&＃xff0c;因为增加了中间层&＃xff0c;不过可以通过缓存机制来改善。
2. 可能会导致级联的修改。这种修改尤其体现在自上而下的方向&＃xff0c;不过可以通过依赖倒置来改善。

六边形架构

六边形架构或六角形架构是Alistair Cockburn在2005年提出&＃xff0c;解决了传统的分层架构所带来的问题&＃xff0c;实际上它也是一种分层架构&＃xff0c;只不过不是上下或左右&＃xff0c;而是变成了内部和外部

六边形架构又称为端口-适配器&＃xff0c;这个名字更容器理解。六边形架构将系统分为内部&＃xff08;内部六边形&＃xff09;和外部&＃xff0c;内部代表了应用的业务逻辑&＃xff0c;外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信&＃xff0c;端口代表了一定协议&＃xff0c;以API呈现。一个端口可能对应多个外部系统&＃xff0c;不同的外部系统需要使用不同的适配器&＃xff0c;适配器负责对协议进行转换。这样就使得应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动&＃xff0c;并且&＃xff0c;可以在与实际运行的设备和数据库相隔离的情况下开发和测试。

六边形架构解决了什么问题

传统的分层架构具有广泛的应用&＃xff0c;例如经典的三层架构&＃xff0c;把系统分为表示层、业务逻辑层、数据访问层。在Martin Fowler的《企业应用架构模式》一书中做过深入阐述&＃xff0c;本书04年出版&＃xff0c;时至今日分层架构仍然是常用的设计方法&＃xff0c;分层架构可以降低耦合、提高复用、分而治之&＃xff0c;但同时也还是存在一些问题&＃xff1a;

1. 分层不清晰、相互依赖严重&＃xff0c;系统无法方便地进行自动化测试。

2. 另外应用程序之间的相互驱动变得很困难&＃xff0c;有时甚至不可能的
3. 传统的分层架构是一维的结构&＃xff0c;有时应用不光是上下的依赖&＃xff0c;可能是多维的依赖&＃xff0c;这时一维的结构就无法适应了。

优势

不论用户端交互问题还是服务端数据库编程问题&＃xff0c;其同源原因就是在设计和实现过程中出现的业务逻辑混淆&＃xff0c;以及与外部实体之间的交互关系。我们要关注的非对称性不是应用的"左边"和"右边"&＃xff0c;而是它的"内部"和"外部"&＃xff0c;该属于"内部"的代码就不要泄露到"外部"去&＃xff0c;其基础理论还是那些基本的设计原则。

六边形架构的核心理念是&＃xff1a;应用通过"端口"跟外部进行交互的。"端口"让人联想到操作系统的端口&＃xff0c;任何符合协议的设备都可以被插到相应的端口上。端口的协议是为了两个设备之间能够进行通信而设计的&＃xff0c;位于OSI 7层协议模型中的传输层。

对应用来说&＃xff0c;API就是协议。对于每一个外部设备&＃xff0c;都有对应的适配器把API转换成自己所需要的信号&＃xff0c;反之亦然。用户图形界面就是一个很好的例子&＃xff0c;它是把用户操作映射到端口API的适配器&＃xff0c;还有其它的例子如自动测试套件&＃xff0c;批处理驱动器&＃xff0c;以及任何需要跨应用程序交互的代码。

对于应用的数据处理层面&＃xff0c;应用通过与外部实体交互得到数据&＃xff0c;这里用到的协议一般指数据库协议。从应用角度来看&＃xff0c;把SQL数据库迁移到普通的文件或者其它类型的数据库&＃xff0c;API仍然保持不变。适应于同一个端口的适配器还包括SQL适配器&＃xff0c;文件适配器&＃xff0c;以及更重要的数据库mock&＃xff0c;它可以是驻存在内存里的数据库&＃xff0c;不一定是真实的数据库。

很多应用都只有两个端口&＃xff1a;用户端端口和数据库端端口。这种情况看起来是对称的&＃xff0c;很自然地就会用单维度多层次的架构来构建它。在开发应用程序时&＃xff0c;就是我们经常看到的三层、四层或五层架构。这种架构有两个问题&＃xff1a;

1. 很容易跨越层间的边界&＃xff0c;把业务逻辑渗透到其它层中去。
2. 有的应用可能不止需要两个端口&＃xff0c;所以不能用单维度架构来构建。

这就是六边形架构提出的原因&＃xff0c;它着重解决对称性问题&＃xff0c;应用通过端口与外部进行交互&＃xff0c;而外部的实体也可以用同样的方式来处理。六边形架构强调以下两点&＃xff1a;

首先&＃xff0c;通过"内外"的不对称性以及端口的特点&＃xff0c;摆脱单维度多层次架构的束缚。可以定义不同数量的端口&＃xff0c;2个&＃xff0c;3个或者4个&＃xff0c;这里说的六边形不限于只有六个边&＃xff0c; 可以根据需要加入更多的端口和适配器&＃xff0c;"六边形架构"只是视觉上的一种叫法。

其次&＃xff0c;关注整体架构的结果导向&＃xff0c;一个端口对应一个或一组有目的交互行为。但一个端口一般会有多个适配器&＃xff0c;可以是无人应答机&＃xff0c;语音留言机&＃xff0c;按键电话&＃xff0c;用户图形界面&＃xff0c;测试套件&＃xff0c;批处理驱动器&＃xff0c;HTTP接口&＃xff0c;程序之间的接口&＃xff0c;mock的数据库&＃xff0c;或者真实的数据库。

从应用层面来看&＃xff0c;这一架构的目的是将注意力聚焦在内外非对称性上&＃xff0c;让外部的实体从应用视角来看都是一样的。

关注的点

• 关注点
  对于分层架构中层次的界定&＃xff0c;Martin Fowler给出了一个判定的方法&＃xff0c;就是如果把表示层换成其他实现&＃xff0c;如果和原来的表示层有重复实现的内容&＃xff0c;那么这部分内容就应该放到业务逻辑层。那么如何让开发人员在系统设计过程中始终保持这种视角&＃xff0c;传统的分层架构是难以做到的。六边形架构有一个明确的关注点&＃xff0c;从一开始就强调把重心放在业务逻辑上&＃xff0c;外部的驱动逻辑或被驱动逻辑存在可变性、可替换性&＃xff0c;依赖具体技术细节。而业务逻辑相对更加稳定&＃xff0c;体现应用的核心价值&＃xff0c;需要被详尽的测试。

• 外部可替换
  一个端口对应多个适配器&＃xff0c;是对一类外部系统的归纳&＃xff0c;它体现了对外部的抽象。应用通过端口为外界提供服务&＃xff0c;这些端口需要被良好的设计和测试。内部不关心外部如何使用端口&＃xff0c;从一开始就要假定外部使用者是可替换的。六边形的六并没有实质意义&＃xff0c;只是为了留足够的空间放置端口和适配器&＃xff0c;一般端口数不会超过4个。适配器可以分为2类&＃xff0c;“主”、“从”适配器&＃xff0c;也可称为“驱动者”和“被驱动者”。

• 自动测试
  在六边形架构中&＃xff0c;自动化测试和用户具有同等的地位&＃xff0c;在实现用户界面的同时就需要考虑自动化测试。它们对应相同的端口。六边形架构不仅让自动化测试这件事情成为设计第一要素&＃xff0c;同时自动化测试也保证应用逻辑不会泄露到用户界面&＃xff0c;在技术上保证了层次的分界。

• 依赖倒置
  六边形架构必须遵循如下规则&＃xff1a;内部相关的代码不能泄露到外部。所谓的泄露是指不能出现内部依赖外部的情况&＃xff0c;只能外部依赖内部&＃xff0c;这样才能保证外部是可以替换的。对于驱动者适配器&＃xff0c;就是外部依赖内部的。但是对于被驱动者适配器&＃xff0c;实际是内部依赖外部&＃xff0c;这时需要使用依赖倒置&＃xff0c;由驱动者适配器将被驱动者适配器注入到应用内部&＃xff0c;这时端口的定义在应用内部&＃xff0c;但是实现是由适配器实现。

CQRS架构

CQRS本身只是一个读写分离的思想&＃xff0c;全称是&＃xff1a;Command Query Responsibility Segregation&＃xff0c;即命令查询职责分离。一个命令表示一种意图&＃xff0c;表示命令系统做什么修改&＃xff0c;命令的执行结果通常不需要返回&＃xff1b;一个查询表示向系统查询数据并返回。另外一个重要的概念就是事件&＃xff0c;事件表示领域中的聚合根的状态发生变化后产生的事件&＃xff0c;基本对应DDD中的领域事件&＃xff1b;

CQRS架构的核心出发点是将整个系统的架构分割为读和写两部分&＃xff0c;从而方便我们对读写两端进行分开优化&＃xff1b;

CQRS架构的一致性模型为最终一致性。

采用CQRS架构的一个前提是&＃xff0c;你的系统要接受系统使用者查询到的数据可能不是最新的&＃xff0c;而是有几个毫秒的延迟。之所以会有这个前提&＃xff0c;是因为CQRS架构考虑到&＃xff0c;作为一个多用户同时访问的互联网应用&＃xff0c;当在高并发修改数据的情况下&＃xff0c;比如秒杀、12306购票等场景&＃xff0c;用户UI上看到的数据总是旧的。比如你秒杀时提交订单前看到库存还大于0&＃xff0c;但是当你提交订单时&＃xff0c;系统提示你宝贝卖完了。这个就说明&＃xff0c;在这种高并发修改同一资源的情况下&＃xff0c;任何人看到的数据总是Stale的&＃xff0c;即旧的。

实现方式

1.最常见的CQRS架构是数据库的读写分离&＃xff1b;

2.底层存储不分离&＃xff0c;上层逻辑代码分离&＃xff1b;

3.各自分离&＃xff0c;底层存储分离&＃xff0c;上层逻辑代码分离。

Q端的数据&＃xff0c;由C端采用Event Sourcing&＃xff08;简称 ES&＃xff09;模式技术进行同步&＃xff0c;所有 C 端的最新数据全部用 Domain Event 表达即可&＃xff0c;而要查询显示用的数据&＃xff0c;则从 Q 端的 ReadDB&＃xff08;关系型数据库&＃xff09;查询即可。

同步方式有两种&＃xff1a;同步或异步&＃xff0c;如果需要 CQ 两端的强一致性&＃xff0c;则需要用同步&＃xff1b;如果能接受 CQ 两端数据的最终一致性&＃xff0c;则可以使用异步。

CQRS架构的适用场景

1. 应用的写模型和读模型差别比较大时
2. 对系统的查询性能和写入性能分开进行优化时&＃xff0c;尤其是读/写比非常高的系统&＃xff0c;CQ分离是必须的。
3. 当希望我们的系统同时满足高并发的写、高并发的读的时候&＃xff1b;因为CQRS架构可以做到C端最大化的写&＃xff0c;Q端非常方便的提供可扩展的读模型&＃xff1b;

缺陷

• 数据有一定的延迟