六边形架构和插件式架构

保留所有版权，请引用而不是转载本文（原文地址 https://yeecode.top/blog/28/ ）。

在《软件复杂性的因素与解决思路》一文中我们说过，软件中技术逻辑和业务逻辑的混杂是导致软件系统复杂化的原因之一。为了降低软件的复杂度，我们需要尽量将软件中的技术逻辑和业务逻辑拆分开来。

在通常的软件架构中，我们使用分层设计来实现两者的拆分。而领域驱动设计中的六边形架构则带来了新的拆分思路，进一步的，作者总结工作经验给出了插件式的拆分思路。

六边形架构

应用业务逻辑往往需要两个端口，一个是面向界面的端口，一个是面向持久层的端口。因此，我们往往会依据这两个端口将整个应用分层，进而实现业务逻辑和技术逻辑的拆离。例如典型的三层结构包含：接口层、业务层、持久层。

在这种设计中，可能还会存在更多的层级，例如持久层又细分为service层、dao层等。而且，各个层级中可能还会穿插模型（Model）层。

在这种分层的设计中，往往出现业务逻辑的碎片化。业务逻辑可能会散落到各个层级，例如，在SQL语句、模型方法、逻辑层中都存在业务逻辑，最终导致系统的混乱。

六边形架构则忽略“上下”、“左右”的层级划分，而是主张“内外”。内层是指业务逻辑，外层是指接口。它是说，应用要以业务逻辑为核心，通过接口与外部系统进行交互。从其要表达的思想上看，“六边形”架构被称之为“同心圆”架构更为合适，因为它并不强调边的数目。

在六边形结构中，持久化功能只是一个挂载到业务逻辑核心上的外围系统，通过持久化接口与业务核心进行交互。同样的，客户端、WEB界面、服务API都是外围系统，通过特定的接口与业务逻辑核心进行交互。

这种思想下，业务逻辑是核心，通过接口对外服务。外围系统多一方，架构也就多一个边，但无论外围系统怎么增加，接口都不会涉及业务逻辑。

插件式架构

六边形架构强调了业务逻辑的核心作用，而与之相对，我们可以以技术逻辑为核心，而将业务逻辑作为插件插入到应用中。

在这种思想下，技术逻辑实现的是一个通用的平台。而业务逻辑则插接到平台上完成对应的功能。

实现这种架构时要实现技术平台的通用性和易用性，以便于能够满足业务逻辑的需要。这种通用性和易用性不仅仅表现在某个业务逻辑内部，也表现在业务逻辑之间。因为，在某些场景下，业务逻辑之间需要通过平台进行互相的协作。

规则引擎系统就是这种模型的良好实践，系统本身提供对规则的解析能力，而规则来决定业务逻辑。

服务网格也是这种模型的良好实践，系统本身提供了服务发现和调用能力，业务应用只需要完成业务逻辑便可以插接到服务网格中享受这些服务。

在插件式结构中，技术逻辑是核心，业务逻辑是插件。这种方式也能保证两类逻辑的松耦合。

总结

本文介绍了六边形架构的核心思想，并结合工作实践提出了插件式架构。这两种架构方案都利于实现业务逻辑和技术逻辑的拆分，进而降低应用的复杂性，可供大家在进行软件架构时结合具体场景灵活选用。

可以访问个人知乎阅读更多文章：易哥（https://www.zhihu.com/people/yeecode），欢迎关注。

作者书籍推荐