本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 在 上建置六邊形架構 AWS *Furkan Oruc、Dominik Goby、Darius Kunce 和 Michal Ploski，Amazon Web Services (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 有助於管理業務複雜性，並在開發新功能時擴展工程團隊。它使用無處不在的語言，使業務和技術利益相關者與稱為*網域*的業務問題保持一致。六角形架構是這種方法在非常特定網域中的技術實現者，稱為*邊界內容*。邊界內容是業務問題高度凝聚且鬆散耦合的子區域。建議您針對所有企業軟體專案採用六邊形架構，無論其複雜性為何。 六角形架構會鼓勵工程團隊先解決業務問題，而傳統分層架構則會將工程焦點從網域轉移到先解決技術問題。此外，如果軟體遵循六邊形架構，則更容易採用[測試驅動的開發方法](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)，從而減少開發人員測試業務需求所需的意見回饋迴圈。最後，使用[命令和命令處理常](https://www.cosmicpython.com/book/chapter_10_commands.html)式是從 SOLID 套用單一責任和開放關閉原則的一種方式。遵守這些原則會產生程式碼庫，開發人員和架構師可以輕鬆導覽和了解專案，並降低將突破性變更引入現有功能的風險。 本指南適用於軟體架構師和開發人員，他們有興趣了解為其軟體開發專案採用六邊形架構和 DDD 的優勢。它包含為 AWS 支援六邊形架構的應用程式設計基礎設施的範例。如需實作範例，請參閱 AWS 規範指引網站上的[使用 在六邊形架構中建構 Python 專案 AWS Lambda](https://docs.aws.amazon.com//prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html)。