最佳實務 - AWS 規範指引
建立商業領域的模型從頭開始編寫並運行測試定義域的行為自動化測試和部署使用微服務和 CQRS 來擴展您的產品設計映射到六角形建築概念的項目結構

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

最佳實務

建立商業領域的模型

從業務領域回到軟件設計，以確保您正在編寫的軟件符合業務需求。

使用領域驅動設計 (DDD) 方法，例如事件風暴來建立商業領域的模型。事件風暴具有靈活的研討會形式。在研討會期間，領域和軟件專家共同探討業務領域的複雜性。軟體專家使用研討會的交付項目，開始軟體元件的設計和開發程序。

從頭開始編寫並運行測試

使用測試驅動開發（TDD）來驗證您正在開發的軟件的正確性。TDD 在單元測試級別效果最好。開發人員通過首先編寫一個測試來設計軟件組件，該測試調用該組件。該組件一開始沒有實現，因此測試失敗。作為下一步，開發人員實現組件的功能，使用帶有模擬對象的測試夾具來模擬外部依賴關係或端口的行為。當測試成功時，開發人員可以繼續實作真正的介面卡。這種方法提高了軟件質量並導致更易讀的代碼，因為開發人員了解用戶將如何使用這些組件。六角形架構通過分離應用程序核心來支持 TDD 方法。開發人員撰寫專注於網域核心行為的單元測試。他們不必編寫複雜的適配器來運行他們的測試; 相反，他們可以使用簡單的模擬對象和固定裝置。

使用行為驅動開發（BDD）來確保在功能級別 end-to-end 接受。在 BDD 中，開發人員定義功能的場景，並與業務利益相關者進行驗證。BDD 測試使用盡可能多的自然語言來實現這一目標。六角形架構以其主要和次要介面卡的概念來支援 BDD 方法。開發人員可以建立可在本機執行的主要和次要介面卡，無需呼叫外部服務。他們將 BDD 測試套件設定為使用本機主要介面卡來執行應用程式。

在持續集成管道中自動運行每個測試，以不斷評估系統的質量。

定義域的行為

將網域分解為實體、值物件和彙總 (請參閱有關實作領域導向設計的資訊)，並定義其行為。實現域的行為，以便在項目開始時編寫的測試成功。定義呼叫網域物件行為的命令。定義網域物件完成行為後所發出的事件。

定義介面卡可用來與網域互動的介面。

自動化測試和部署

在初始概念證明之後，我們建議您投入時間實施實 DevOps踐。例如，持續整合與持續交付 (CI/CD) 管線和動態測試環境可協助您維持程式碼品質，並避免部署期間發生錯誤。

  • 在 CI 進程中運行單元測試，並在合併之前測試您的代碼。

  • 建置 CD 程序，將應用程式部署至靜態開發/測試環境，或是動態建立的支援自動整合與 end-to-end測試的環境。

  • 將專用環境的部署程序自動化。

使用微服務和 CQRS 來擴展您的產品

如果您的產品成功，請將您的軟體專案分解為微服務來擴展產品規模。利用六角形架構提供的可攜性來提高性能。將查詢服務和命令處理常式拆分為單獨的同步和非同步 API。考慮採用命令查詢責任隔離 (CQRS) 模式和事件驅動架構。

如果您收到許多新功能要求，請考慮根據 DDD 模式調整組織的規模。如同先前在織檢視本節中所討論的，使其擁有一或多個特徵作為有界前後關聯的方式來建構您的專案團隊。然後，這些團隊可以通過使用六角形體系結構實現業務邏輯。

設計映射到六角形建築概念的項目結構

基礎架構即程式碼 (IaC) 是雲端開發中廣泛採用的做法。它可讓您將基礎結構資源 (例如網路、負載平衡器、虛擬機器和閘道) 定義和維護為原始程式碼。如此一來，您就可以使用版本控制系統來追蹤架構的所有變更。此外，您可以建立和移動基礎結構輕鬆進行測試。我們建議您在開發雲端應用程式時，將應用程式程式碼和基礎結構程式碼保存在相同的儲存庫中。此方法可讓您輕鬆維護應用程式的基礎架構。

我們建議您將應用程式分成三個資料夾或專案，這些資料夾或專案會對應到六角形架構的概念：entrypoints(主要介面卡)、domain (網域和介面) 和adapters (次要介面卡)。

下列專案結構提供了在上設計 API 時此方法的範例AWS。該項目將應用程序代碼（app）和基礎結構代碼（infra）保存在同一個存儲庫中，如前所述。

app/  # application code
|--- adapters/  # implementation of the ports defined in the domain
     |--- tests/  # adapter unit tests
|--- entrypoints/  # primary adapters, entry points
     |--- api/  # api entry point
          |--- model/  # api model
          |--- tests/  # end to end api tests
|--- domain/  # domain to implement business logic using hexagonal architecture
     |--- command_handlers/  # handlers used to run commands on the domain
     |--- commands/  # commands on the domain
     |--- events/  # events emitted by the domain
     |--- exceptions/  # exceptions defined on the domain
     |--- model/  # domain model
     |--- ports/  # abstractions used for external communication
     |--- tests/  # domain tests
infra/  # infrastructure code

如前所述，域是應用程序的核心，不依賴於任何其他模塊。建議您建立domain資料夾的結構，使其包含下列子資料夾：

  • command handlers包含在網域上執行命令的方法或類別。

  • commands包含定義在網域上執行作業所需資訊的命令物件。

  • events包含透過網域發出，然後路由至其他微服務的事件。

  • exceptions包含網域內定義的已知錯誤。

  • model包含網域實體、值物件和網域服務。

  • ports包含網域與資料庫、API 或其他外部元件進行通訊的抽象概念。

  • tests包含在網域上執行的測試方法 (例如商務邏輯測試)。

主要介面卡是應用程式的進入點，如entrypoints資料夾所示。此範例使用資api料夾做為主要轉接器。此資料夾包含 APImodel，用來定義主要介面卡與用戶端通訊所需的介面。該tests文件夾包含對 API 的 end-to-end 測試。這些是淺層測試，用於驗證應用程序的組件是否集成並協調工作。

次要配接器 (如adapters資料夾所表示) 會實作網域連接埠所需的外部整合。資料庫儲存庫是次要介面卡的一個很好的範例。當資料庫系統變更時，您可以使用網域所定義的實作來寫入新的配接器。不需要變更網域或業務邏輯。tests子資料夾包含每個介面卡的外部整合測試。