在動態且不斷變化的技術世界中構建滿足企業和用戶的需求和期望的軟件可能具有挑戰性。軟件公司逐漸需要一種可行的方式來讓業務和產品團隊之間的溝通更加透明。領域驅動設計（DDD）方法通過促進對主題的深刻理解以及開發人員和業務專家之間的持續協作來幫助解決這個問題。事實上，開發人員通過不斷的溝通，對底層領域和業務規則有了更深入的了解。同時，利益相關者可以更好地了解技術能力和限制。

例如，Standish Group對 100 個項目的分析發現，70% 的返工是由于需求和設計階段缺乏領域知識造成的，這證實了 DDD 促進了企業和開發人員之間的理解。

據Forrester稱，實踐迭代 DDD 模型的開發團隊比花費數月進行前期分析的工作速度快 60%。

劍橋大學進行的研究發現，在 DDD 框架內對領域知識進行建?？梢允箞F隊生產力提高 29%。顯然，這種方法解鎖了內部領域知識。

那么為什么企業需要這種方法，誰使用它，它的本質是什么？

領域驅動設計的核心原則

以領域為中心的設計基于幾個關鍵概念，這些概念支持創建以領域為中心的軟件。

● 首先是領域模型的優先級。它代表底層的業務實體、行為、關系和規則。代碼實現直接反映領域模型，而不是相反。該模型是迭代開發的，而不是提前預定的。

● 另一個核心原則是開發一種通用語言。開發人員和業務專家的共享詞匯標準化了術語和領域知識，消除了團隊之間的歧義和不一致。

● DDD 還包括戰略和戰術設計階段。戰略設計側重于作為有界上下文和子區域的領域的高層組織。戰術設計包含模式和較低級別的實現組件，例如實體、服務和存儲庫。

其他概念包括強調探索性建模而不是分析、持續的領域沉浸以及使用通用語言進行文檔記錄。

通過結合建模、語言和基于上下文的技術，DDD 能夠創建不僅關注技術需求而且關注領域核心概念的系統。

在這種背景下，六邊形架構和干凈架構立即浮現在腦海中，它們具有任務分離的共同目標。您可以通過將應用程序劃分為松散耦合的組件來將核心業務邏輯與外部問題隔離。

讓我們看看定義戰略和戰術設計的元素以及它們如何影響結果。

策略設計

在 DDD 的背景下，戰略設計是軟件開發的重要組成部分。它主要包括以下幾個方面：

● 概述。戰略設計從對問題領域和業務價值的概述開始。在此步驟中，將探索關鍵概念和流程，并確定關鍵業務需求和目標。

● 問題空間和解決方案空間。戰略設計框架確定了兩個主要概念空間：問題空間和解決方案空間。問題空間側重于探索和分析業務領域，識別實體、聚合、服務以及它們之間的關系。解決方案空間涉及創建一個有效解決問題空間中確定的問題的模型。

● 受限的環境。受限上下文是與特定開發團隊的職責范圍相對應的領域的有限細分。每個上下文都定義其實體、聚合、服務和規則。管理上下文邊界對于隔離和理解域的不同部分至關重要。

● 核心域。核心域是業務的核心，是業務最重要、最有價值的部分。在戰略設計中，核心領域至關重要，因為它是開發的重點，并且包含定義軟件功能的基本抽象和業務規則。

DDD 背景下的戰略設計可以通過考慮業務領域的特征來創建有效的軟件開發戰略。這有助于開發人員創建滿足業務需求、靈活擴展且易于維護的軟件。

戰術設計

戰術設計是軟件開發方法的一部分。它負責定義一組工具和方法來創建反映業務領域并確保數據完整性的高效且靈活的架構。

• 首先概述業務領域及其需求。此步驟分析核心流程、實體、聚合以及它們之間的關系。目標是更深入地了解該領域的核心組件。
• 接下來，我們關注應用程序的核心，也稱為核心聚合。核心聚合是主要交互元素，包含域的關鍵邏輯和數據完整性。它定義了核心操作和業務規則。
• 繼續討論戰術設計工具包，它為我們提供了一組用于構建有效的應用程序架構的規則和模式。它包括值對象、實體、服務和聚合等概念。該工具包可幫助開發人員創建敏捷架構。
• 使用戰術設計工具包的一個例子是創建存儲庫。存儲庫負責從特定實體或聚合的存儲庫中存儲和檢索數據。它們提供與數據存儲庫交互的單一接口并封裝數據存儲細節。

戰術設計還區分應用程序服務和領域服務。應用程序服務協調應用程序內不同實體和聚合之間的操作和交互。對于領域服務，它們存儲僅與領域模型相關的業務邏輯和操作執行。

總而言之，戰術設計有助于創建反映業務領域并保證數據完整性的有效架構。使用戰術設計工具可以簡化應用程序開發和支持，從而更容易理解和擴展復雜領域。

有界上下文和通用語言：它們在 DDD 中的作用

DDD 中的有界上下文是應用于特定業務領域的一組本地化模型和規則。它有助于在特定上下文中描述和限制系統的不同方面。

有界上下文代表開發發生的邊界，并確保該上下文中模型和規則的一致性。因此，它可以有自己的建模語言，甚至特定于業務領域的術語。

它使開發人員能夠更好地理解和建模復雜的主題領域，并促進利益相關者的溝通。有限的上下文可以并行存在并通過定義的接口進行交互。

當我們談論 DDD 時要關注的另一個同樣重要的概念是無處不在的語言。

它可以被描述為所有開發團隊成員使用和理解的通用語言。

通用語言是在有限的上下文中創建和維護的。它包括反映系統的業務理解和主題的專業術語、短語和規則。這種語言作為熟悉的基礎，促進不同團隊成員之間的有效溝通。

其主要任務是幫助避免與術語或概念的不同解釋和理解相關的誤解，并在某種意義上有助于對主題領域進行更深入、更準確的建模。

開啟新解決方案的關鍵：DDD 方法帶來了什么，它適合誰？

如果一個項目處理復雜的業務邏輯、不斷變化的流程、關系和業務規則，那么它就成為實現領域驅動設計原則的理想選擇。通過應用 DDD，開發人員可以有效地駕馭復雜領域并創建準確反映現實世界復雜性的軟件解決方案。

DDD 對未來的變化也具有很強的適應性和靈活性。隨著企業的發展并面臨新的挑戰，軟件解決方案必須跟上步伐。有限上下文的明確分離和通用語言的使用促進了更新和修改的無縫集成，從而最大限度地減少了重大系統范圍更改的需要。其結果是實現平穩過渡、減輕壓力水平并節省公司成本。

小型 DDD 團隊的力量

領域驅動設計非常適合小型自治團隊。“雙比薩團隊”的概念就體現了這一點。我們的想法是，一個團隊應該足夠小，只需兩個披薩就可以養活。這可以實現專注、協調和生產力。

我們看到“雙披薩團隊”方法與 DDD 交織在一起，成功應用于 Netflix（這使他們能夠快速擴展平臺）和 Uber（他們能夠靈活地隔離事件并管理需求波動）等行業領導者。

看起來 DDD 是一個專屬俱樂部，成員包括 Netflix、Uber 和我們不起眼的 WebLab Technology。我們是很好的伙伴，不是嗎？

是的，我們使用 DDD 作為開發復雜業務軟件的主要方法之一。我們似乎是少數與之合作的公司之一。

有人在DEV 社區門戶上發起了討論，詢問“如何找到遵循領域驅動設計方法的公司？”

要找到 DDD 從業者，請遵循結構良好的對話……或者只是尋找我們的團隊！

但有人決定建議你可以找到這樣的公司，如果他們在提案中提到他們與 DDD 合作。需求是有的，但報價并不多。

正如您所看到的，小型、有凝聚力的團隊在復雜的領域中發揮著至關重要的作用。他們可以快速積累知識并普遍使用其領域的語言。

對于采用 DDD 的公司來說，采用“兩塊披薩”團隊范式可以釋放跨領域的生產力和創新。小團隊和領域驅動設計的聯系是強大的。

特別是，DDD 能夠：

● 改進的溝通：無處不在的語言使開發人員和業務專家能夠更有效地協作。

● 業務一致性：軟件設計直接反映真實的業務流程和目標。

● 靈活性：模塊化架構使得可以根據需求的變化輕松修改應用程序。

● 以用戶為中心：以領域為中心，可以創建適合用戶需求的解決方案。

● 效率：主題專家的密切參與可以產生能夠解決實際業務問題的產品。

DDD 和小型組織：可能的挑戰

在較小的組織中，DDD 集成可能不像在較大的公司中那樣普遍。然而，整合的能力取決于具體的需求和優先事項。如果小型組織具有復雜的主題領域或需要有效管理和建模業務流程，那么 DDD 集成可能會很有幫助。

但是，請為可能出現的障礙做好準備，其中包括：

● 資源有限。較小的組織可能擁有有限的開發人員和時間，這使得實施新方法具有挑戰性。

● 主題建模困難。DDD 集成需要對主題領域有深入的了解并對其進行正確的建模。缺乏軟件開發經驗可能是一個障礙。

● 抵制變革。較小的組織可能更容易抵制變革，特別是在現有流程和軟件架構已經建立的情況下。

● 技術限制。過時的技術基礎設施不支持完整的 DDD 集成。

事實上，并非所有這些障礙都適用于所有小型組織。每個組織都有可能影響 DDD 集成的獨特特征和挑戰。

DDD實施：逐步開始

現在，讓我們看看有效實施 DDD 的基本步驟，而不被復雜性所困擾。

1 . 從小事做起

建議從小規模開始使用 DDD，尤其是剛接觸它或處理大型系統時。選擇應用程序中一個小的、不太關鍵的部分并開始應用 DDD。

2.持續學習

通常，第一次實施可能并不完美。這是一個持續學習的過程。不要因最初的挑戰而灰心喪氣。了解錯誤并從中吸取教訓。

3.協作

DDD 不僅僅與編碼人員有關。它涉及整個團隊：開發人員、項目經理、系統分析師、領域專家等。它需要緊密協作，根據業務需求進行知識共享和軟件開發。

最后，正如我們之前所說，必須記住 DDD 并不總是適用于所有項目的解決方案。對于簡單的應用程序來說，它引入的復雜性可能不是必需的，因此評估其在項目中的需求至關重要。

交叉點：DDD 與敏捷的聯系

那么，DDD 與 Agile 的交集如何體現呢？DDD 和敏捷有著相似的原則，為它們的成功集成奠定了基礎。

• 與利益相關者積極互動。在 DDD 中，這體現在普遍使用促進有效溝通的語言，而敏捷則側重于協作來創造價值。
• 靈活性和適應性。兩種方法都是適應性強的。敏捷旨在接受和實施變更，而 DDD 模型則不斷發展以反映領域理解。
• 迭代開發。敏捷專注于以小規模、漸進的步驟開發軟件。在 DDD 中，模型隨著發展而不斷完善，這讓我們回到了敏捷 DDD 的迭代本質。

DDD 和敏捷之間的聯系表現為一種互補關系。因此，在敏捷環境中使用 DDD 可以簡化溝通，確保更好地符合業務需求，并交付高質量的軟件。

我們可以自信地說，嚴重依賴領域知識的行業在 DDD 專注于學習其特定領域的復雜性方面發現了特殊的價值。最終，以領域為中心的設計的本質在于它能夠創建與企業及其客戶的需求緊密結合的高質量軟件。

對于WebLab Technology來說，DDD 方法是我們與客戶建立長期技術合作伙伴關系的理念的一個組成部分。它符合康威定律，該定律指出軟件系統反映了構建它們的組織的通信結構。

我們的專業團隊創建的架構與客戶的領域自然契合，領域專家的深度參與使我們能夠創建一個涉及每個人的順暢的溝通鏈。也許越多的公司意識到這種方法的必要性，未來就會發現更有價值的 DDD 好處。

畢竟，正如埃里克·埃文斯（Eric Evans）在他的書中所寫的那樣，“為了有效地溝通，代碼必須基于用于編寫需求的相同語言 - 開發人員彼此以及與領域專家交談的相同語言?！?/span>