領域驅動設計的概念解釋 -DEV

複雜性挑戰
複雜性是一個相對術語。一個人的複雜性對另一個人而言簡單。但是，複雜性是DDD應解決的問題。在這種情況下，複雜性意味著互連，許多不同的資料來源，不同的業務目標等。
DDD方法是在這裡解決軟體開發的複雜性。另一方面，當挑戰很簡單時，您可以使用緊急設計。但是，當您的應用程式很複雜時，複雜性只會增加，您的問題也會隨之增加。
DDD設計基於業務域：現代商業環境非常複雜，錯誤的舉動可能導致致命的後果。域驅動的設計解決了複雜的域模型，並連線到核心業務概念。
埃裡克·埃文斯（Eric Evans）於2004年在他的著作《域驅動設計：解決軟體中心的複雜性》中介紹了這一概念。根據這本書，它著重於三個原則：

• 該專案的主要重點是核心領域和領域邏輯。
• 複雜的設計基於領域的模型。
• 技術專家和領域專家之間的協作對於建立可解決特定領域問題的應用程式模型至關重要。

域驅動設計中的重要術語
在DDD中，請注意以下術語，這一點很重要：
1.領域邏輯：領域邏輯是建模的目的。最通常地，它被稱為業務邏輯。這是您的業務規則定義資料建立、儲存和修改方式的地方。
2.領域模型：領域模型包括圍繞您要解決的問題的想法，知識，資料，指標和目標。它包含將幫助您處理複雜業務邏輯的所有規則和模式。而且，它們將對滿足您的業務要求很有用。
3.子域：領域由幾個子域組成，這些子域引用業務邏輯的不同部分。例如，線上零售商店可以將產品目錄，庫存和交付作為其子域。
4.設計模式：設計模式都是關於重用程式碼的。無論您遇到什麼複雜的問題，一直在進行物件導向程式設計的人都可能已經建立了一種模式來幫助您解決它。將您的問題分解為最初的要素將使您找到解決方案。透過模式學習的所有內容，以後都可以用於開始程式設計的任何物件導向的語言。
5.有界的上下文：有界上下文是域驅動設計中的中心模式，其中包含應用程式的複雜性。它處理大型模型和團隊。在定義了領域domain和子域subdomains之後，在這裡實現程式碼。
有界上下文實際上表示在其中定義並適用某個子域的邊界。在這裡，特定的子域有意義，而其他則沒有意義。一個實體在不同的上下文中可以具有不同的名稱。當有界上下文中的子域發生更改時，整個系統也不必更改。這就是開發人員在上下文之間使用介面卡的原因。
6.無所不在的語言：通用語言是一種方法，它指的是領域專家和開發人員在談論他們正在使用的領域時所使用的相同語言。這是必要的，因為專案可能會遇到語言中斷的嚴重問題。發生這種情況是因為領域專家使用了自己的行話。同時，技術專業人員使用他們自己的術語來談論該領域。
日常討論中使用的術語與程式碼中使用的術語之間存在差距。這就是為什麼必須定義每個人都使用的一組術語的原因。通用語言中的所有術語都是圍繞領域模型構建的。
7.實體：實體是資料和行為的組合，例如使用者或產品。它們具有身份，但是代表具有行為的資料點。
8.值物件和聚合：值物件具有屬性，但不能單獨存在。例如，送貨地址可以是值物件。大型而複雜的系統具有無數的實體和值物件。這就是為什麼領域模型需要某種結構。這會將它們分為易於管理的邏輯組。這些組稱為集合。它們代表了相互連線的物件的集合，目的是將它們視為一個單位。而且，它們也具有聚合根。這是聚合之外的任何物件都可以引用的唯一實體。
9.領域服務：域服務是一個附加層，其中還包含域邏輯。它是域模型的一部分，就像實體和值物件一樣。同時，應用程式服務是不包含業務邏輯的另一層。但是，這裡是在域模型上方協調應用程式的活動。
10.Repository儲存資料庫：儲存庫模式是業務實體的集合，可簡化資料基礎結構。它從基礎結構方面釋放了域模型。分層概念強制將關注點分離。

領域驅動設計示例
例如，如果我們使用電子商務應用程式，則業務領域將是處理訂單。當客戶想要下訂單時，他們首先需要檢查產品。然後，他們選擇所需的商品，確認訂單，選擇運輸型別並付款。然後，該應用會處理客戶端提供的資料。
因此，使用者應用程式將由以下幾層組成：
1.使用者介面：客戶可以在這裡找到下訂單所需的所有資訊。在電子商務案例中，這就是產品所在的位置。該層將資訊提供給客戶端並解釋其行為。
2.應用層：該層不包含業務邏輯。這是將使用者從一個使用者介面引導到另一個使用者介面螢幕的部分。它還與其他系統的應用程式層進行互動。它可以執行簡單的驗證，但不包含與域相關的邏輯或資料訪問。其目的是組織和委託域物件來完成其工作。而且，它是其他有界上下文可訪問的唯一層。
3.領域層：這就是業務領域的概念所在。該層具有有關業務案例和業務規則的所有資訊。這也是實體所在的位置。如前所述，實體是資料和行為的組合，例如使用者或產品。
它們具有透過唯一鍵保證的唯一身份，即使其屬性發生更改，它們仍然保留。例如，在電子商務商店中，每個訂單都有唯一的識別符號。它必須經過確認和發貨之類的若干操作才能被視為一個實體。
另一方面，值物件沒有唯一的識別符號。它們代表各種實體可以共享的屬性。例如，這可以是不同客戶的相同姓氏。
這部分還包含具有定義的操作行為的服務，這些服務不必屬於任何域。但是，它們仍然是業務領域的一部分。服務根據普遍使用的語言命名。他們不應剝奪實體並重視物件的明確責任心和行動。客戶應該能夠使用任何給定的服務例項。在應用程式的生命週期中該例項的歷史記錄應該不是問題。
最重要的是，域層位於業務應用程式的中心。這意味著應將其與其餘各層分開。它不應該依賴於其他層或它們的框架。
4.基礎設施層：該層支援其他層之間的通訊，並且可以包含UI層的支援庫。

領域驅動設計的優勢

• 通訊更簡單。多虧了無處不在的語言，開發人員和團隊之間的交流變得更加容易。由於無所不在的語言可能包含開發人員所引用的簡單術語，因此不需要複雜的技術術語。
• 更大的靈活性。由於DDD是物件導向的，因此有關該域的所有內容均基於該物件，並且物件是模組化和籠狀的。因此，可以定期修改和改進整個系統。
• 該域位於UI / UX之前。由於域是中心概念，因此開發人員將構建適合於特定域的應用程式。這不會是另一個以介面為中心的應用程式。儘管您不應該忽略UX，但是使用DDD方法意味著該產品將完全針對直接連線到域的使用者。

領域驅動設計的缺點

• 需要深入的領域知識。即使是從事開發工作的技術最先進的團隊，團隊中也至少要有一位領域專家，他們瞭解作為應用程式中心的主題領域的精確特徵。有時，需要一些完全瞭解該領域的團隊成員併入開發團隊。
• 包含重複性做法。儘管許多人會說這是一個優勢，但是域驅動的設計包含許多重複性的實踐。DDD鼓勵使用持續整合來構建功能強大的應用程式，這些應用程式可以在必要時進行自我調整。許多組織可能在使用這些方法時遇到困難。更具體地說，如果他們以前的經驗通常與諸如瀑布模型之類的較不靈活的增長模型相關聯。
• 對於高科技專案，它可能不是最好的方法。域驅動的設計非常適合具有複雜業務邏輯的應用程式。但是，對於領域複雜度較小但技術複雜度較高的應用程式，它可能不是最佳解決方案。對於面向業務的領域專家來說，技術複雜性很高的應用程式可能會非常具有挑戰性。這可能會導致許多限制，而這些限制可能並非所有團隊成員都能解決。

結論
域驅動設計是一種解決特定域模型的軟體工程方法。透過將執行與關鍵業務原則聯絡起來，該解決方案繞過業務模型。
域專家和開發團隊之間的通用術語包括域邏輯，子域，有界上下文，上下文對映，域模型和無處不在的語言，以作為協作和改進應用程式模型以及解決任何與域相關的挑戰的方式。
在本文中，我們想定義圍繞域驅動設計的核心概念。此外，我們想對它們進行解釋，並新增該方法的優點和缺點。這樣，我們希望可以幫助您確定這是否是適合您的業務和應用程式的方法。

微服務提供了一些嚴重的優於傳統的架構，提供可擴充套件性，可訪問性和靈活性。此外，由於每個微服務都是一個鬆散耦合的服務，只有一種責任感，因此這種方法使開發人員能夠集中精力。