你應該使用領域驅動設計嗎？ - codeopinion

大型系統
首先，讓我定義一些我將在這篇文章的其餘部分中提到的內容。在談論系統的設計時，我指的是一個足夠大的系統，它會影響組織內的許多不同角色/人員/部門。即使那個組織很小，也有不同的人在其中扮演不同的角色。
所以我在這篇文章中所指的並不是一個具有最少功能集的小型應用程式。相反，它是一個更大的系統，具有針對組織內許多不同角色的各種業務能力。
作為一個具體的例子，我將在這篇文章的其餘部分使用它，假設我們正在構建一個用於送餐服務的系統。我對送餐很天真，但是，我確實有運輸方面的背景，所以使用這個例子的目的是每個人都可能使用過送餐服務，所以你可能可以獲得高水平。
在這個系統中，我們需要提供各種功能。我們有一些 CRM 來管理我們所有的客戶，有一些型別的訂單供客戶下訂單，HR 來管理運送食物的司機，以及從餐廳實際向客戶運送食物。
  

邊界
微服務帶來的好處之一是承認邊界。每個邊界都定義了它的能力和它擁有的資料。
然而，這裡的關鍵是並非所有邊界都是平等建立的。這意味著不同的邊界服務於不同的目的，在整個系統中具有不同的價值水平。
一些邊界對業務域的核心更多的支援作用：CRM 和 HR 可能更多地扮演訂購和交付的支援角色。根據我們的需求，支援角色的邊界內沒有那麼複雜。因此，它們可能足夠通用，您可以使用 SaaS 或 3rd 方產品，並可能與之整合。
其他一些支援邊界可能不夠通用，因此您必須開發它們，但它可以更多地由 CRUD 驅動，而不需要太多複雜性。
也許我們可以開發了自己的 HR 應用程式，但這只是為了保留送貨司機的基本人口統計資料。
而訂購和交付邊界是複雜性所在，也是我們正在構建的系統的核心。
 

邏輯邊界
我提到微服務帶來的一件好事是邊界。不幸的是，假設邊界必須是物理邊界並且必須獨立部署。然而，重點應該首先放在簡單地定義我上面所說的邏輯邊界上。您不必開發微服務或可獨立部署的服務。您可以開發一個由邏輯邊界組成的單體。

每個邊界仍然擁有自己的資料和模式。CRM 和會計是通用的，我們正在利用我們正在整合的外部 SaaS。我們不需要建立自己的會計系統或 CRM，這不是問題或解決方案的空間。
我們系統的核心可能由長期執行的業務流程組成。當客戶訂購食物時，我們必須通知餐廳，然後讓司機拿起食物並將食物交付給客戶。這是構成該工作流程的一系列業務流程。這是您關心領域驅動設計的地方。嘗試對這些業務流程進行建模並在我們的程式碼中捕獲我們領域的語言。
在支援角色的那些邊界中，我們只是不需要進行太多分析來對領域的那部分進行建模。這樣做沒有足夠的價值，因為這不是我們想要關注的解決方案空間。這些邊界可以是外部的，也可以只是 CRUD。
 

能力
既然邊界很重要，那麼您如何定義邊界是什麼以及它們提供了哪些功能？
業務流程可以特定於單個邊界，也可以跨越多個邊界。通常，從一個邊界完成其部分的越區切換從下一個邊界開始。
部門和角色是考慮邊界的另一種方式。您系統的終端使用者在任何給定時間都可能為給定任務履行某個角色。他們想要完成什麼？
邊界是一種權威，有責任管理或處理流程的某個部分。
邊界包含如何執行給定過程的知識。但最重要的是，它的目標是什麼？它打算做什麼？
 

上下文為王
如果您正在為我們的系統開發 HR 模組，是的，也許我們的送貨司機的地址只是簡單的 CRUD。但是，如果我們正在開發郵政/郵件服務，那麼更改地址將具有更多的複雜性和過程。如果您要更改地址，是因為搬到新位置嗎？是否需要郵件轉發之類的東西？這根本不可能是 CRUD。在這種情況下，不僅僅是“更新地址”。這可能更像是一個需要捕捉的商業概念。上下文很重要。
CRUD如果不是特定型別的資料，例如地址、名稱等，如果它是關於有關指定上下文中的資料實現增刪改查，它就要值得重視。
 

你應該使用領域驅動設計嗎？
如果您正在開發一個核心複雜的大型系統，那麼是的，我建議您檢視領域驅動設計中的一些戰略（和戰術）模式。如果您要圍繞功能和語言（有界上下文）定義邊界，猜猜怎麼著？你已經在做領域驅動設計了！
如果您正在編寫一個相對較小且沒有太多複雜性的應用程式，請不要試圖應用戰術模式。