一、前言

斷斷續續的也有在閒餘時間接觸領域驅動設計的相關知識，因為目前在工作中更多的還只是一名 crud boy，因此目前也只是對其中的某些知識點有知曉，實際使用的比較少，僅此而已。因此，趁著這個春節假期，整理了一下自己的 github 帳號，同時結合自己定的學習計劃以及自己的期望發展方向，決定從一個真實的案例來梳理領域驅動的相關知識。

本篇文章是開篇，因為領域驅動設計相關的知識真的不怎麼好懂，如果行文中出現錯誤的地方，歡迎大家在評論區指出，先行感謝。

當然，talk is cheap, show me the code，作為一名 .NET 開發人員，例項中的服務端程式碼全部是基於 ASP.NET Core 框架進行搭建的。

二、系列目錄

1. 我的領域驅動設計運用例項 - 領域啊領域

三、Step by Step

不清楚大家在接觸領域驅動的相關知識時，是不是一上來就是領域驅動經典的四層架構，然後什麼是實體、值物件、聚合，它們之間有什麼異同以及與傳統的開發模式又是什麼，領域模型又是什麼東東，最終接觸到一大堆的概念，結合上網搜到的示例專案程式碼，結果最後就知道了幾個名詞。

當然，這些都是領域驅動設計中比較重要的知識點，可能是自己入行較短，按照上面的這個順序看了一遍，看完之後，嗯，貌似最後都沒看完，我只能是下面的這種表情。。。因此，為了不讓像我這樣的小白使用者一上來就用藥過猛，所以這裡我換一種方式來嘗試解釋我所認為的領域驅動設計，如若存在偏差，希望可以幫忙指出。

第一篇介紹的是我認為領域驅動設計中一個最基礎的東西，也是很多文章中並沒有說的，如何去識別出業務領域並進行劃分。

1、案例分析

因為在識別領域時，需要做到對於業務流程有比較深刻的瞭解，至少應該做到有相關軟體的使用經歷，因此在這個系列的文章中，我選擇的是專案管理軟體作為文章的示例專案。最終實現的各種需求是基於禪道專案管理軟體這個開源專案的，因此，在開發這個專案之前，我們可以先看看禪道這個專案管理系統中所包含的功能模組。畢竟，只有在瞭解需求之後才好進行下一步的工作。

在這個開源的專案管理系統中，主要包含了如下的幾個功能。

除了一些基礎的許可權相關功能，站在專案產品的角度，禪道包含了對於產品的分支、團隊成員、迭代版本、功能模組、功能需求等資料資訊的維護，同時針對專案可以去設定各種任務、以及可以提 bug 等等任務操作。

當然，系統所包含的功能還可以繼續往下展，如果按照我們面向資料庫開發的經驗，在弄清楚系統的各項功能後，可能就是去建各種的表了，繼而識別出各個表之間的關聯關係，然後就 ctrl c、ctrl v 的開幹了。當然，這裡既然選擇採用一種新的方式進行開發，忘掉我們原來的經驗，從一個新的角度開始。

2、領域劃分

領域驅動設計，在維基百科中對於領域的解釋如下，因為詞條的中文解釋應該是機翻的，所以這裡放出英文原文，下方的中文是我基於個人理解所提供的翻譯，僅供參考。

A sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software;

領域是一種關於知識、影響或是活動的範圍限定。軟體的領域是使用者想要通過使用該程式所要達到的主體功能。

範圍，即是邊界，能夠置於相同範圍內的事物必定是具有著某種相同的特性，我們通過程式碼的手段來解決現實中的問題時，也會將某些共通的業務放到一塊。

因此，在使用領域驅動的思想來指導軟體開發的過程中，我們需要按照一定的業務規則將期望達成的業務進行細分，在最終劃分出的一個個小業務範圍內，通過建立領域模型的方式，指導程式碼實現，從而解決具有共同特性的問題，因此，領域驅動設計中的領域就是這個業務邊界範圍內想要解決的業務問題域。

接下來，針對我們期望實現的專案管理系統，就是需要按照一定的業務規則，完成我們的業務領域的劃分。

• 第一步：確定研究物件，明確我們將要研究的業務領域，識別出最終需要解決的業務問題；

  我們最終想要實現的目標是一個專案管理系統，因此這裡我們的研究物件就是專案管理。

• 第二步：對研究物件按照一定的業務邏輯進行細分，將領域進一步的劃分成多個子領域；

  從上面瞭解到的期望實現的系統功能中看出來，基於各個專案管理中不同業務的特性，我們可以將專案管理這個領域拆分成專案子域、版本子域、任務子域等等。

• 第三步：對識別出的子領域再次進行細化，從而識別出子領域中的最小單元，從而確定所需要研究的範圍邊界；

  在識別出領域的各個子域之後，我們需要對子域進行進一步的細化，當不能再細化的時候，我們就可以在這個限界上下文中去建立該子領域的領域模型，從而構建出程式碼模型，完成最終的程式設計開發。

就像上面列出的步驟一樣，我們在對業務領域進行不斷的拆分中，會劃分出不同的子域。對於業務來說，某些業務很重要，某些可能就無關緊要。因此在劃分子領域的過程中，通過子域的重要性和業務功能屬性的差異，我們可以將其區分成核心子域、通用子域、以及支撐子域。

核心子域是我們需要解決的業務核心問題，支撐子域是支撐我們的核心子域實現的業務，而通用子域則更多的是每個系統中一些通用的業務功能，例如，認證、授權等等。因此，在實現業務時，我們應該將核心子域的建設擺在首位。

按照上面的步驟，識別出的業務領域如下圖所示，因為這裡的領域劃分，更多的是我個人的想法，所以會存在思考不完善的地方，如果你有別的看法，歡迎指出。

可以看到，這裡其實只是識別出了比較粗放的業務子領域，並沒有完成對於業務最小單元的邊界識別。因為這塊的內容會與領域建模關聯比較大，所以統一放到下一篇文章中，通過介紹如何用事件風暴的方式完成對於業務領域的建模時一起介紹。

嗯，其實就是完全沒想好怎麼寫。。。

三、個人總結

• 領域驅動的核心是完成對於領域模型的定義，從而確定業務和應用邊界，保證我們的業務模型與程式碼模型一致性；
• 領域驅動是一種架構設計的方法論，通過圍繞實際業務構建領域模型的方式將複雜的業務領域逐步的拆分，幫最終找出最基礎的業務功能與其對應的最基礎功能應用的邊界；
• 領域是用來確定功能的範圍，範圍即是邊界，相同的業務問題應該限制在特定的一個功能範圍中。一個業務領域可以繼續劃分，最終實現將業務域進行不斷的拆解，從而降低對於整體業務的理解和系統實現的複雜度；

四、參考資料

• 阿里盒馬領域驅動設計實踐
• DDD理論學習系列——案例及目錄
• 淺談我對DDD領域驅動設計的理解