在14年读《实现领域驱动设计》接触到六边形架构，感觉很受启发，每个限界上下文就对应一个六边形架构：
后来又学习了《架构整洁之道》里面的整洁架构，和六边形结合起来看，明白了其精华在于让业务内核稳定，基础设施处于外围作为技术实现手段，去依赖业务内核，架构模型体现为从外向里依赖。
我弄懂后，开始在团队内部进行推广，但是发现大家不容易理解记忆，什么时候用防腐层ACL，什么时候用开放主机服务OHS，大家还是习惯于传统分层架构的从上向下的依赖方向，感觉费了很大的劲才让大家明白。落地过程中，因为理解偏差，时不时发生这样那样的问题，最常见的问题是让领域层依赖了基础设施。
后来接触了张逸老师提出的菱形对称架构（Rhomboid Symmetric Architecture），咋一看不太对，怎么把资源库放在了领域层（domain）之下的接口层（菱形对称架构称之为端口层），后来仔细琢磨，其实和六边形架构本质一样，也符合整洁架构的模型。
既然本质一样，干嘛提出菱形对称架构呢？
经历过前面落地的艰难，才能体会到菱形的价值。
原来这种架构模型更加符合程序员的思维习惯。大多数程序员习惯“从上向下的”传统分层架构，典型的分层：
展现层 -> 业务层 -> 持久层 -> 数据库层
菱形也是“从上向下的”。分析一下对于限界上下文的一次典型调用的运行时过程，从北向网关的远程服务层 -> 应用服务层 -> 领域层 -> 南向网关端口层 -> 适配器层持久化到数据库，非常容易理解。
端口层是接口Interface，领域层（实际上是领域层内的领域服务）依赖端口层，适配器层实现端口层，这里需要依赖倒置。
明显可以看出：南向网关需要依赖倒置，充当防腐层ACL，而北向网关是不需要依赖倒置的，就是开放主机服务OHS。这样的分解要比六边形架构更好理解。总感觉六边形有点过于抽象，理解有些烧脑。
实践中，程序员们对南向网关作为防腐层ACL容易理解接受，当把资源库Repository从domain层转移到端口层和其它端口元素统一管理后，立刻感觉到整个代码结构非常的整齐划一、清晰易读，让DDD的理念落地的简单自然。
菱形对称架构典型（推荐）的代码模型如下图所示：
这样的代码结构是非常清晰的，只要团队遵循这一模式，就能形成一致的代码模型，便于理解和沟通。
