一、前言
斷斷續續的也有在閑余時間接觸領域驅動設計的相關知識，因為目前在作業中更多的還只是一名 crud boy，因此目前也只是對其中的某些知識點有知曉，實際使用的比較少，僅此而已，因此，趁著這個春節假期，整理了一下自己的 github 帳號，同時結合自己定的學習計劃以及自己的期望發展方向，決定從一個真實的案例來梳理領域驅動的相關知識，
本篇文章是開篇，因為領域驅動設計相關的知識真的不怎么好懂，如果行文中出現錯誤的地方，歡迎大家在評論區指出，先行感謝，
當然，talk is cheap, show me the code，作為一名 .NET 開發人員，實體中的服務端代碼全部是基于 ASP.NET Core 框架進行搭建的，
二、系列目錄
- 我的領域驅動設計運用實體 - 領域啊領域
三、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領域驅動設計的理解
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/3102.html
標籤：領域驅動設計
上一篇：CDC+ETL實作資料集成方案
下一篇：單例模式