在軟體開發中，有一個永恆的難題：業務邏輯越來越複雜，程式碼越來越難維護。早期基於MVC架構的CRUD應用運作良好，但隨著業務深入，開發團隊很快就會陷入一個困境——“業務邏輯到底該放在哪裡？”
領域驅動設計（Domain-Driven Design，簡稱DDD），正是為解決這個難題而生。它由軟體大師Eric Evans在2003年提出，旨在透過將業務領域知識作為系統設計的核心驅動力，建構與業務高度對齊的軟體模型。 DDD不是一種具體的架構風格，而是一套完整且有系統的設計方法，它透過邊界劃分將複雜業務領域簡化，幫助我們設計出清晰的領域和應用邊界。
本文將系統解譯DDD的核心概念、策略設計與戰術設計、分層架構等內容，無論你是剛接觸DDD的開發者，或是希望提升架構設計能力的產品經理或架構師，都能從中獲得啟發。
在傳統開發模式中，業務邏輯往往與資料庫操作、框架特性混雜在一起，導致程式碼可讀性差、維護成本高。 DDD的核心思想是將純業務邏輯與技術實現徹底分離，讓開發者能夠像業務專家一樣思考問題。
DDD的首要原則是建立統一語言（Ubiquitous Language） 。所有人員——包括開發人員、測試人員、產品經理、業務專家——都應使用一套統一的、基於領域模型的通用語言。這意味著程式碼中的類別名稱、方法名稱必須直接反映業務概念，而不是含義模糊的DataProcessor或Manager。例如，電商系統中應該有Order類別及其place()（下單）方法，而不是一個通用的OrderService臃腫地把所有邏輯都裝進去。
DDD的第二個核心理念是聚焦核心領域（Core Domain） 。在一個複雜的業務系統中，不同子域的業務價值不同。核心域是業務成功的關鍵因素，需要投入最多的設計精力；通用域是多個子域共享的通用功能；支撐域則是支撐其他子域的基礎設施。
DDD的實踐分為兩個維度：戰略設計和戰術設計。策略設計著重領域劃分與邊界定義，解決「做什麼」；戰術設計聚焦在具體程式碼實現，解決「怎麼做」。
面對一個龐大的系統，試圖用單一的模型來涵蓋所有業務範圍是不切實際的。 DDD的策略設計部分提供了劃分複雜系統的強大工具。
領域是指企業要解決的問題領域。以內容社群系統為例，整個「內容社群」就是領域，它可以分解為使用者管理、讀者、付款、社群等多個子網域。其中社區可能屬於核心域，而支付屬於支撐域。
核心提示：在策略設計中，重要的是識別哪些子域是業務的核心競爭力所在，並集中資源投入。
這是DDD中最重要的策略模式。它明確地界定了一個模型的應用範圍，即「在哪個邊界內，這個字是什麼意思」。例如，「產品」在電商的商品脈絡中，擁有價格、描述、類目等屬性；而在物流上下文中，「產品」則更關注重量、體積。
每個限界上下文都是一個獨立的“語義疆界”，其內部擁有統一的通用語言和領域模型。系統因此被分解為多個高內聚、低耦合的模組。
關鍵原則：限界上下文透過上下文映射（Context Map）明確與其他上下文的關係，避免模型污染。
DDD與微服務架構自然契合。一個設計良好的限界上下文，天然就是一個微服務的候選者。反之，盲目地依照技術層次拆解系統，極易導致分散式單體－服務雖拆，耦合依舊。在微服務架構中，一個服務應該不小於一個聚合，不大於一個限界上下文。
在限界上下文內部，DDD提供了一系列戰術建模工具來建構領域模型。
實體是具有唯一識別和生命週期的物件。例如，一個使用者即使更改了姓名，其唯一ID不變，它依然是同一個實體。實體通常採用充血模型，即把業務行為封裝在實體內。
值物件沒有唯一標識，僅透過其屬性值來區分，通常不可變。例如，金額（Money）由幣種和數值決定，兩個金額和幣種相同的Money可以互換。合理使用值物件可以減少系統複雜性，例如地址、郵箱、電話號碼等均可建模為值物件。
聚合是一組相關實體和值物件的集合，它們作為整體被管理。聚合根是聚合中的核心實體，負責維護聚合內的一致性。例如，Order聚合根管理OrderItem和Payment實體，所有對訂單項目的存取都必須透過Order進行。
聚合設計原則：聚合邊界內的交易應保持一致，引用其他聚合時應僅透過標識，避免跨聚合的直接引用。聚合應設計得盡量小。
這是初學者最容易混淆的概念。領域服務承載無法歸屬於實體或值物件的領域行為，屬於領域層，維持領域純度，不涉及技術細節。例如，TransferService處理跨帳戶轉賬，它不屬於任何一個帳戶實體，但也是核心業務邏輯。
應用服務協調領域物件和領域服務，處理應用程式的工作流程，屬於應用層。應用程式服務是無狀態的，負責用例的調度、事務管理和安全性認證，但不包含業務規則。
倉儲（Repository） 是領域層與基礎設施層的橋樑，定義在領域層作為抽象接口，基礎設施層實現具體儲存邏輯。倉儲只暴露按聚合存取的方法，不暴露ORM細節。
領域事件（Domain Event） 是領域內發生的有意義的業務事件，可以用來觸發後續的業務邏輯，實現模組間的解耦。
DDD建議採用分層架構，典型分為四層：使用者介面層、應用層、領域層、基礎設施層。
負責與用戶交互，接收請求並回傳回應。在Web應用中對應Controller，但僅負責參數校驗和結果格式化，不包含業務邏輯。
協調領域物件完成業務用例，處理事務邊界、安全性和認證。應用層服務保持無狀態，只呼叫領域服務或聚合根方法，不包含業務規則。
DDD的核心，包含所有業務規則和模型。定義聚合根、實體、值物件和領域服務，確保業務邏輯的完整性。
提供技術實作支持，如資料庫存取、訊息佇列、外部API呼叫等。透過依賴倒置原則，領域層定義接口，基礎設施層實現它們，實現業務邏輯與技術實現的徹底隔離。
DDD分層架構的依賴方向是由外向內：使用者介面層依賴應用層，應用層依賴領域層，基礎設施層透過依賴倒置被領域層定義介面。領域層不依賴任何具體框架或技術，這使得核心業務邏輯可以在不修改的情況下取代技術方案。
在DDD落地實踐中，視覺化是幫助團隊建立共識的關鍵環節。無論是戰略設計階段的限界上下文劃分，或是戰術設計階段的領域模型構建，都離不開清晰的圖表。而ProcessOn作為專業的線上圖表工具，可以有效率地支援DDD架構的全流程視覺化。
1. 進入ProcessOn個人文件頁，創建“流程圖”，或直接在模板社區搜尋DDD架構設計等關鍵字；
2. 左側「更多圖形」可以選擇流程圖、UML圖等圖形類別加入到圖形庫，圖形庫拖曳矩形框、圓形等圖形到畫布，用帶箭頭的連線可以連結不同元素表達依賴關係；
3. 选中单个或多个元素，顶部工具栏可以用不同颜色区分不同层次的模型，以及进行图形对齐、图层设置等布局；
4. 绘制完成后，可以点击右上角分享协作将DDD架构图分享给同事或客户持续迭代模型，也可以导出高清图片、PDF、SVG等格式留存。
领域驱动设计不只是一套技术模式或架构规范，它更是一场思维革命，和一套应对软件核心复杂性的系统化方法论。它教导我们：软件开发不是从建表开始，而是从理解业务开始。
通过战略设计划定领域边界，通过战术设计构建高内聚的领域模型，结合分层架构实现业务逻辑与技术实现的隔离，DDD能够显著提升复杂业务系统的可维护性和可扩展性。尤其是在微服务时代，DDD提供的限界上下文划分方法，正是科学拆分微服务的最佳实践。
免費線上協同心智圖流程圖
