六边形架构（Ports and adapters）：适配器间通信的规范与选型咨询

一、不同适配器通信的正确实现方式 #

拿你提到的“从Elasticsearch获取文档，并用S3存储的信息丰富该文档”场景来说，正确的做法是通过应用层定义的抽象端口来协调，而非适配器直接互调。

具体落地步骤：

1. 在应用层定义抽象端口，比如DocumentEnricherPort，声明获取补充数据的方法；
2. 让S3适配器实现这个端口，把从S3读取数据的逻辑封装在实现类中；
3. Elasticsearch适配器依赖这个抽象端口，而非直接依赖S3适配器的具体实现；
4. ES适配器拿到原始文档后，通过注入的端口实例调用S3的能力，完成文档丰富。

伪代码示例：

# 应用层抽象端口
class DocumentEnricherPort:
    def get_enrichment_data(self, doc_id: str) -> dict:
        raise NotImplementedError

# S3适配器实现端口
class S3EnrichmentAdapter(DocumentEnricherPort):
    def __init__(self, s3_client):
        self.s3_client = s3_client

    def get_enrichment_data(self, doc_id: str) -> dict:
        obj = self.s3_client.get_object(Bucket="data-bucket", Key=f"{doc_id}_meta.json")
        return json.load(obj["Body"])

# ES适配器依赖抽象端口
class ESDocumentFetcherAdapter:
    def __init__(self, es_client, enricher: DocumentEnricherPort):
        self.es_client = es_client
        self.enricher = enricher

    def fetch_and_enrich(self, doc_id: str) -> dict:
        raw_doc = self.es_client.get(index="docs", id=doc_id)["_source"]
        enrichment_data = self.enricher.get_enrichment_data(doc_id)
        raw_doc.update(enrichment_data)
        return raw_doc

这种方式严格遵循端口与适配器的依赖倒置原则：所有外部依赖（包括其他适配器）都通过内部抽象端口访问，保证应用/领域层不被外部实现绑定。

二、适配器直接调用彼此公共方法是否合规？ #

严格来说，这种做法违背了端口与适配器模式的核心设计原则。

端口与适配器模式的核心是隔离外部系统，让内部层（领域、应用）只依赖抽象，外部适配器依赖内部抽象。如果适配器直接互调，会导致：

• 适配器之间形成强耦合，修改一个适配器的实现可能直接影响另一个；
• 破坏分层隔离的初衷，适配器本应是对接外部的“转换器”，现在变成互相依赖的组件，架构复杂度会快速上升；
• 测试难度增大：测试ES适配器时，无法轻松mock掉S3的具体实现，只能依赖真实服务或编写复杂测试桩。

当然，极小且不会迭代的简单场景下这么做可能短期省事，但从长期维护和扩展性来看，绝对不推荐。

三、权威资料获取渠道 #

• 模式提出者Alistair Cockburn的原始论述：他最早将其命名为“Hexagonal Architecture（六边形架构）”，可查找他的论文、演讲或博客内容；
• 《实现领域驱动设计》（Implementing Domain-Driven Design）：书中有章节专门讲解六边形架构与DDD的结合，详细说明了端口和适配器的职责与通信规则；
• Martin Fowler的架构专栏：他对六边形架构的解读通俗易懂，适合入门理解；
• 行业社区实践讨论：比如Stack Overflow上的相关问题，很多资深架构师会分享实际项目的落地经验。

四、适配器层内部使用端口通信的优缺点 #

优点 #

• 彻底解耦适配器：适配器之间只依赖抽象端口，互不绑定具体实现，替换或升级其中一个适配器时，其他组件无需修改；
• 测试友好：可以用mock实现端口，轻松隔离各个适配器的逻辑，单元测试不用依赖外部服务；
• 架构一致性：严格遵循依赖倒置和分层原则，系统架构边界更清晰，新人更容易理解；
• 扩展性强：如果后续需要替换外部服务（比如把S3换成腾讯云COS），只需要实现同一个端口即可，调用方完全不用改代码。

缺点 #

• 初期额外工作量：需要定义额外的抽象端口，多写一些接口代码，对小项目来说可能显得繁琐；
• 团队认知成本：需要团队成员理解端口与适配器的设计思想，否则容易出现误用（比如把端口定义在适配器层）；
• 简单场景的过度设计：功能固定、不会迭代的小型系统中，这种设计可能增加不必要的复杂度。

内容的提问来源于stack exchange，提问作者Phreneticus