本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 概述 ## 域驱动型设计 (DDD) 在[域驱动设计 (DDD)](https://www.oreilly.com/library/view/implementing-domain-driven-design/9780133039900/) 中，域是软件系统的核心。在开发任何其他模块之前，首先定义域模型，它不依赖于其他低级模块。相反，诸如数据库、表示层和外部之类的模块 APIs 都依赖于域。 在 DDD 中，架构师使用基于业务逻辑的分解而不是技术分解，将解决方案分解为有限的上下文。本[目标业务成果](#business-outcomes)节讨论了这种方法的好处。 当团队使用六角形架构时，DDD 更容易实现。在六角形架构中，应用程序核心是应用程序的中心。它通过端口和适配器与其他模块分离，并且不依赖于其他模块。这与 DDD 完全一致，其中，域是解决业务问题的应用程序的核心。本指南提出了一种方法，将六角形架构的核心建模为有界上下文的域模型。下一节将更详细地介绍六角形架构。 本指南并未涵盖DDD的所有方面，这是一个非常广泛的话题。为了更好地理解，您可以查看[域名语言](https://www.domainlanguage.com/ddd/)网站上列出的DDD资源。 ## 六角形架构 Hexagonal 架构，也称为*端口和适配器*或*洋葱架构*，是管理软件项目中依赖关系反转的原理。Hexagonal 架构促进在开发软件时高度关注核心领域的业务逻辑，并将外部集成点视为次要集成点。Hexagonal 架构可帮助软件工程师采用诸如测试驱动开发 (TDD) 之类的良好实践，这反过来又可以促进[架构的演进](https://dzone.com/articles/pattern-of-the-month-red-green-refactor)，并帮助您长期管理复杂的领域。 让我们比较一下六角形架构和经典的分层架构，后者是建模结构化软件项目的最常用选择。这两种方法之间存在微妙但很大的区别。 在分层架构中，软件项目是分层结构的，这代表了广泛的关注点，例如业务逻辑或演示逻辑。这种架构使用依赖关系层次结构，其中顶层依赖于其下方的层，但不相反。在下图中，表示层负责用户交互，因此它包括用户界面、 APIs、命令行界面和类似的组件。表示层依赖于实现域逻辑的业务层。反过来，业务层依赖于数据访问层和多个外部服务。 ![经典分层建筑](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/hexagonal-architectures/images/layered.png) 这种配置的主要缺点是依赖结构。例如，如果在数据库中存储数据的模型发生变化，则会影响数据访问接口。对数据模型的任何更改也会影响业务层，业务层依赖于数据访问接口。因此，软件工程师无法在不影响域逻辑的情况下对基础架构进行任何更改。这反过来又增加了出现回归错误的可能性。 六角形架构以不同的方式定义依赖关系，如下图所示。它围绕定义所有接口的域业务逻辑进行决策。外部组件通过称为*端口*的接口与业务逻辑交互。端口是定义域与外部世界交互的抽象概念。每个基础架构组件都必须实现这些端口，因此这些组件的更改不再影响核心域逻辑。 ![六角形架构](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/hexagonal-architectures/images/hexagonal.png) 周围的组件称为*适配器*。适配器是外部世界和内部世界之间的代理，它实现了域中定义的端口。适配器可以分为两组：主适配器和辅助适配器。主适配器是软件组件的入口点。它们允许外部参与者、用户和服务与核心逻辑进行交互。 AWS Lambda 是主适配器的一个很好的例子。它与多个 AWS 服务集成，这些服务可以调用 Lambda 函数作为入口点。辅助适配器是处理与外部世界通信的外部服务库封装器。辅助适配器的一个很好的例子是用于数据访问的 Amazon DynamoDB 客户端。 ## 目标业务成果 本指南中讨论的六角形架构可帮助您实现以下目标： + [通过改善开发周期来缩短上市时间](improve-dev-cycle.md) + [提高软件质量](improve-software-quality.md) + [更轻松地适应变化](adapt-to-change.md) 以下各节将详细讨论这些过程。