本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL03-BP02 建置專注於特定業務網域和功能的服務
服務導向架構 （SOA） 定義具有業務需求定義之詳細函數的服務。微型服務使用領域模型和有界限的環境，沿著業務環境界限繪製服務界限。專注於業務領域和功能，有助於團隊為其服務定義獨立的可靠性要求。有界限的環境可隔離和封裝商業邏輯，讓團隊更適切地推論如何處理失敗。
預期成果：工程師和業務利益相關者共同定義有界限的環境，並將其用來設計系統，作為滿足特定業務功能的服務。這些團隊使用既定的做法 (如事件風暴) 來定義要求。新的應用程式設計為服務妥善定義的界限和鬆散耦合。現有單體會分解為邊界內容，
領域導向服務會以一或多個不共用狀態的程序執行。它們會單獨回應需求的波動，並根據領域的特定要求來處理錯誤情境。
常見的反模式：
-
團隊是依據特定技術領域 (例如 UI 和 UX、中介軟體或資料庫) 組成的，而不是特定的業務領域。
-
應用程式跨多個領域責任。跨有界限環境的服務可能更難以維護，需要較大量的測試工作，且需要多個領域團隊參與軟體更新。
-
領域相依性 (例如領域實體程式庫) 會跨服務共用，因此一個服務領域出現變更時，需要變更其他服務領域
-
服務合約和商業邏輯無法以通用且一致的領域語言來表達實體，因此會導致翻譯層級使系統複雜化，並增加偵錯工作。
建立此最佳實務的優勢：應用程式設計為獨立的服務，受到業務領域限制，並使用共同的商務語言。服務可以單獨測試和部署。服務符合實作領域的特定恢復能力要求。
未建立此最佳實務時的曝險等級：高
實作指引
網域驅動設計 （DDD） 是圍繞業務網域設計和建置軟體的基礎方法。在建置專注於業務領域的服務時，使用現有架構將有所幫助。使用現有的整合型應用程式時，您可以利用分解模式提供已建立的技術，將應用程式現代化為服務。
領域驅動的設計
實作步驟
-
團隊可舉行事件風暴
研討會，以便箋格式快速識別事件、命令、彙總和領域。 -
在網域環境中形成網域實體和函數之後，可以使用有界限的環境
將網域劃分為服務，其中共用相似特徵和屬性的實體會分組在一起。隨著此模型劃分成多個環境，如何界定微型服務界限的範本便會浮現。 -
例如，Amazon.com 網站實體可能包括包裝、交付、排程、價格、折扣和貨幣。
-
包裝、交付和排程會分組到出貨環境中，而價格、折扣和貨幣則分組到訂價環境中。
-
-
將整合型服務分解為微型服務概述了重構微型服務的模式。按業務功能、子領域或交易使用分解的模式，會與領域驅動的方法保持一致。
-
泡泡內容
等戰術技術可讓您DDD在現有或舊版應用程式中導入 ，而無需預先重寫和對 的完整承諾DDD。在 bubble 環境方法中，使用服務映射和協調或防損毀層 來建立一個小的有界限環境，可保護新定義的網域模型免受外部影響。
在團隊執行網域分析和定義的實體和服務合約之後，他們可以利用 AWS 服務來實作其以雲端為基礎的 服務。
-
藉由定義執行領域商務規則的測試來起始您的開發。測試驅動的開發 （TDD） 和行為驅動的開發 （BDD） 可協助團隊讓服務專注於解決業務問題。
-
在 AWS上建置六邊形架構，它概述了一個框架，用以將業務邏輯建置到從業務領域回溯運作的服務中，以滿足功能要求，然後附加整合適配器。使用 AWS 服務將介面詳細資訊與業務邏輯分開的模式，可協助團隊專注於網域功能並改善軟體品質。
資源
相關的最佳實務：
相關文件：
相關範例：
相關工具：
