本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 在上构建六角形架构 AWS *Furkan Oruc、Dominik Goby、Darius Kunce 和 Amazon Web Services 的 Michal Ploski ()AWS* *2022 年 6 月*（[文档历史记录](doc-history.md)） 本指南描述了用于开发软件架构的心理模型和一系列模式。随着产品采用率的增长，这些架构易于在整个组织中维护、扩展和扩展。诸如 Amazon Web Services (AWS) 之类的云超大规模企业为小型和大型企业提供了创新和开发新软件产品的基石。这些新服务和功能的快速引入使业务利益相关者期望他们的开发团队更快地对新的最低可行产品 (MVPs) 进行原型设计，以便可以尽快测试和验证新的想法。通常， MVPs 它们会被采用并成为企业软件生态系统的一部分。在制作这些规则的过程中 MVPs，团队有时会放弃软件开发规则和最佳[实践，例如SOLID原则](https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/)和单元测试。他们认为这种方法将加快开发速度并缩短上市时间。但是，如果他们未能为所有级别的软件架构创建基础模型和框架，则很难甚至不可能为产品开发新功能。在开发过程中，缺乏确定性和不断变化的要求也会减慢团队的工作速度。 本指南介绍了拟议的软件架构，从低级六边形架构到高级架构和组织分解，该架构使用域驱动设计 (DDD) 来应对这些挑战。随着新功能的开发，DDD 可帮助管理业务复杂性并扩大工程团队规模。它使用无处不在的语言，使业务和技术利益相关者与业务问题（称为*域名*）保持一致。*Hexagonal 架构是一个非常具体的领域（称为有界上下文）中这种方法的技术推动力。*有限的上下文是业务问题中一个高度凝聚力和松散耦合的子领域。我们建议您对所有企业软件项目采用六边形架构，无论其复杂性如何。 Hexagonal 架构鼓励工程团队首先解决业务问题，而传统的分层架构则将工程重点从领域转移到首先解决技术问题上。此外，如果软件遵循六边形架构，则更容易采用[测试驱动的开发方法](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)，从而减少开发人员测试业务需求所需的反馈循环。最后，使用[命令和命令处理程序](https://www.cosmicpython.com/book/chapter_10_commands.html)是应用 SOLID 的单一责任和开放式封闭原则的一种方式。遵循这些原则可以生成一个代码库，开发人员和架构师可以轻松浏览和理解该项目，并降低对现有功能进行重大更改的风险。 本指南适用于有兴趣了解在软件开发项目中采用六角形架构和 DDD 的好处的软件架构师和开发人员。它包括一个为应用程序设计支持六角形架构的基础架构 AWS 的示例。有关实现示例，请参阅 AWS Pr [escriptive Guidence AWS Lambda网站上使用在六角形架构中构建 Python 项目](https://docs.aws.amazon.com//prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html)。