菱形对称架构的表达力

在14年读《实现领域驱动设计》接触到六边形架构，感觉很受启发，每个限界上下文就对应一个六边形架构：

后来又学习了《架构整洁之道》里面的整洁架构，和六边形结合起来看，明白了其精华在于让业务内核稳定，基础设施处于外围作为技术实现手段，去依赖业务内核，架构模型体现为从外向里依赖。

我弄懂后，开始在团队内部进行推广，但是发现大家不容易理解记忆，什么时候用防腐层ACL，什么时候用开放主机服务OHS，大家还是习惯于传统分层架构的从上向下的依赖方向，感觉费了很大的劲才让大家明白。落地过程中，因为理解偏差，时不时发生这样那样的问题，最常见的问题是让领域层依赖了基础设施。

后来接触了张逸老师提出的菱形对称架构（Rhomboid Symmetric Architecture），咋一看不太对，怎么把资源库放在了领域层（domain）之下的接口层（菱形对称架构称之为端口层），后来仔细琢磨，其实和六边形架构本质一样，也符合整洁架构的模型。

既然本质一样，干嘛提出菱形对称架构呢？

经历过前面落地的艰难，才能体会到菱形的价值。

原来这种架构模型更加符合程序员的思维习惯。大多数程序员习惯“从上向下的”传统分层架构，典型的分层：

展现层 -> 业务层 -> 持久层 -> 数据库层

菱形也是“从上向下的”。分析一下对于限界上下文的一次典型调用的运行时过程，从北向网关的远程服务层 -> 应用服务层 -> 领域层 -> 南向网关端口层 -> 适配器层持久化到数据库，非常容易理解。

端口层是接口Interface，领域层（实际上是领域层内的领域服务）依赖端口层，适配器层实现端口层，这里需要依赖倒置。

明显可以看出：南向网关需要依赖倒置，充当防腐层ACL，而北向网关是不需要依赖倒置的，就是开放主机服务OHS。这样的分解要比六边形架构更好理解。总感觉六边形有点过于抽象，理解有些烧脑。

实践中，程序员们对南向网关作为防腐层ACL容易理解接受，当把资源库Repository从domain层转移到端口层和其它端口元素统一管理后，立刻感觉到整个代码结构非常的整齐划一、清晰易读，让DDD的理念落地的简单自然。

菱形对称架构典型（推荐）的代码模型如下图所示：

这样的代码结构是非常清晰的，只要团队遵循这一模式，就能形成一致的代码模型，便于理解和沟通。

¶ 张逸附：

我和京东的周吉鑫老师常常就领域驱动设计的诸多问题展开讨论。无论是老周提出的问题，还是一些回答，往往能给予我不少启发。业务服务的价值就是在和他的一次交流中总结出来的（以后我会专门撰文详述）。老周非常赞成我提出的菱形对称架构，并积极在他的团队中推行和实践。

有一次我在阅读某项目代码时，向老周吐槽这样的代码结构让人看不清楚入口在何方，然后不无得意地说：“我又发现菱形对称架构的一个好处，就是按照这个架构定义的代码模型，你很清楚入口在哪里。”

老周表示赞同：“这正是我喜欢菱形的原因。它符合人的自然思维，把进和出通过北向与南向分开。”于是我撺掇老周：“要不，你写篇文章，谈谈你对菱形对称架构的感受？”于是就有了这篇短文的发布。在此，向周吉鑫老师表示感谢！