提交訂單的職責與調用

🔖標籤 #ddd

[!AI] 本文摘要
在領域驅動設計中，提交訂單的過程涉及客戶作為用戶角色通過前端用戶界面與後端的訂單上下文進行交互，發起服務請求。訂單上下文將提交訂單公開為遠程服務，並使用命名慣例（如以"Controller"或"Resource"結尾）來提高可讀性和理解性。領域驅動設計強調根據限界上下文建模，幫助建立明確的系統邊界，提升可維護性和可理解性，並促進團隊的獨立開發與協作。

在真實世界，由客戶提交訂單，因此客戶是發起提交訂單服務請求的用戶角色。但是，對限界上下文而言，提交訂單是訂單上下文對外公開的遠程服務，調用者並非客戶上下文，而是前端的用戶界面。客戶通過前端與後端的限界上下文進行交互，完成訂單提交的服務請求。提交訂單的職責與調用，從客戶到前端用戶界面圖：

提交訂單的職責與調用

提交訂單的限界上下文和角色

• 限界上下文（Bounded Context）: 在領域驅動設計中，限界上下文代表了特定的領域邊界，這裡的限界上下文是訂單上下文。訂單上下文將提交訂單公開為遠程服務，不同於真實世界中的客戶領域

• 客戶角色：客戶被視為一個用戶角色，通過前端用戶界面與後端限界上下文進行交互來發起提交訂單的服務請求。

遠程服務和使用命名慣例

遠程服務（Remote Service）：提交訂單被公開為遠程服務，以”Controller"作為服務名稱結尾。這意味著前端用戶界面可以調用此遠程服務來完成訂單提交的服務請求。當面對上下文調用時，你可以以"Resource"作為遠程服務的名稱結尾的慣例。例如，如果你的遠程服務是用於提交訂單，你可以將其命名為"OrderResource"或者"OrderSubmissionResource"。這樣的命名慣例可以幫助其他開發者更容易地理解該服務的功能和定位。同時，儘量使用明確和具有描述性的名稱有助於提高代碼的可讀性和可理解性。

領域驅動設計的作用

領域驅動設計：領域驅動設計強調根據場景的限界上下文來建模和組織系統。在本例中，訂單上下文被提取出來，並在該上下文中組織訂單相關的業務邏輯和服務。

重點

領域驅動設計有助於更好地理解問題領域，並在系統的不同部分之間建立明確的邊界，從而提高系統的可理解性和可維護性。它還使不同的團隊能夠根據自己的上下文限制進行獨立開發和演化，同時確保他們之間的集成和協作。