DDD理论学习系列（13）-- 模块
1. 引言
Module，即模塊，是指提供特定功能的相對獨立的單元。提到模塊，你肯定就會想到模塊化設計思想，也就是功能的分解和組合。對于簡單問題，可以直接構建單一模塊的程序。而對于復雜問題，則可以先創建若干個較小的模塊，然后將它們組裝、鏈接在一起，從而構成復雜的軟件系統。
在DDD中，模塊的用途也是如此，通過分解領域模型為不同的模塊，以降低領域模型的復雜性，提高領域模型的可讀性。
2. DDD中的模塊
模塊是一個籠統的概念，比較寬泛，為了正確發揮模塊的威力，理解模塊的概念就十分重要。下面我們從具體的問題著手，來嘗試說明模塊的概念。
如何對在線商城的顧客進行建模？
對于顧客來說，一般需要維護顧客的個人信息、收貨地址、支付方式。這些信息是緊密相關的，不可獨立存在。我們可以抽象出三個簡單的聚合Customer、AddressBook和?Wallet。那這些類該如何存放呢？是為每一個聚合創建一個文件夾存放還是放在同一個文件夾？我想答案不言而喻。
這三個聚合就是一個模塊，一個客戶模塊。通過定義一個Customer文件夾，來將相關聯的領域對象組合起來。而這個文件夾體現在C#中就是命名空間的概念。
再來看一個問題，如何設計在線商城的支付功能？
支付是在線商城中十分重要的一個環節，設計的好壞直接影響項目的成敗。一般來說，針對于支付環節，我們應該單獨放到支付子域中去處理，以維護領域的不變性，支付環節對應支付上下文，在支付上下文下，一些領域概念才能更清晰。為了提升支付體驗，我們勢必要支持多種支付方式，比如支付寶支付、微信支付、其他銀行卡支付。在對接某一種支付方式時，我們就應該為其定義單獨的模塊，保證支付方式的獨立性。同樣，我們可以選擇通過命名空間來實現模塊化，也可以類似NopCommerce創建單獨的項目來插件化開發集成每一種支付方式。同樣，我們也可以將整個支付功能擰出一個單獨的支付模塊，以便在其他項目中進行共用。
如何集成第三方SDK?
我們知道開源的一大好處是，大牛們分享了一系列高效、實用庫或軟件，也就是大家常說的“輪子”，比如Hangfire、RabbitMQ、Dapper、Redis等等，我們可以直接開箱即用。但如果項目中集成很多的第三方SDK，如果不加以組織整理，項目的結構就會比較混亂，代碼的可讀性就大大降低。這個時候我們就可以考慮模塊化的去集成第三方SDK，通過對第三方SDK的再封裝，來完善代碼的組織結構，以達到項目中的統一調用。Abp框架就是通過這種方式來集成比較流行第三方SDK。
通過以上的舉例說明，我們可以看到模塊可大可小，每個模塊都是相對獨立的功能單元。在C＃中我們可以用命名空間或單獨的項目來實現模塊。通過模塊來組織和封裝相關概念，來分解領域模型，以簡化領域模型的復雜性。
但不要將模塊與子域和限界上下文混淆。在復雜的領域模型中，為了對領域模型中進行準確建模，需要將領域模型拆分成多個子域，每個子域對應一個或多個限界上下文。在限界上下文中，可以將限界上下文中具體的領域概念分解成不同的模塊。所以，從子域到限界上下文再到模塊，應該是依次包含關系。
3. 模塊設計的原則
模塊的設計是基于領域模型的，要符合通用語言的表述。其次，模塊的設計要符合高內聚低耦合的設計思想。
3.1. 根據領域來組織模塊
模塊應該由領域的概念來組織，而不是根據通用的組件類型和模式來創建模塊。如果將所有的聚合、服務、工廠分別放在獨立的模塊中，就會有悖于DDD的設計原則，同時還會限制我們創建富有行為的領域模型。這樣設計的模塊的關注點是在當前的組件和模式上，而不是在領域上。每個模塊都應該有適當的類來建模領域的特定方面的概念和功能。
3.2. 基于通用語言
項目中的通用語言除了用來指導實體，值對象、領域服務和領域事件的的命名外，也適用于模塊的命名。使用通用語言來為模塊命名，可以清晰的反映領域中的概念，且能夠明確模塊職責。例如，領域中身份認證的概念，我們就可以以Identity來命名這個模塊。
推薦的模塊命名規范是：公司名稱.項目名稱.架構分層.限界上下文.組件類型。
比如對騰訊微信產品的朋友圈模塊的領域層可以按以下方式命名：
說到這里，你可能會想到mvc的項目結構也是基于模塊的思想，比如Models、Views、Controllers、css、js都是放在獨立的文件夾中，這其實也是關注點分離的思想，通過模塊的分割來達到關注點分離。
3.3. 高內聚低耦合
高內聚低耦合是模塊設計的重要思想，模塊內高內聚，模塊間低耦合。
一個完整的系統，模塊與模塊之間，盡可能的使其獨立存在。也就是說，讓每個模塊，盡可能的獨立完成某個特定的子功能。模塊與模塊之間的接口，盡量的少而簡單。如果某兩個模塊間的關系比較復雜的話，最好首先考慮進一步的模塊劃分，這樣有利于修改和組合。
4. 總結
模塊是對領域模型進行分解后的產物，是相對獨立的功能單元，由一系列高內聚的領域對象組成，相對聚合、實體和值對象來說是更高一層的抽象。
模塊化的思想大大簡化了領域模型的復雜性，即便于我們設計出高內聚低耦合的系統，也便于我們理解系統的設計。
而至于模塊的實現，我們既可以通過命名空間來進行分離，也可以使用單獨的項目來實現。
參考資料
What are Modules in Domain Driven Design?
相關文章
DDD理論學習系列（1）-- 通用語言
DDD領域驅動之干貨 （一）
DDD理論學習系列（2）-- 領域
DDD理論學習系列（3）-- 限界上下文
DDD理論學習系列（4）-- 領域模型
事件總線知多少（2）
DDD理論學習系列（5）-- 統一建模語言
DDD理論學習系列（6）-- 實體
DDD理論學習系列（7）-- 值對象
DDD理論學習系列（8）-- 應用服務&領域服務
DDD理論學習系列（9）-- 領域事件
DDD理論學習系列（10）-- 聚合
DDD理論學習系列（11）-- 工廠
DDD理論學習系列（12）-- 倉儲
從事件和DDD入手來構建微服務
DDD領域驅動之干貨 （一）
WeText項目：一個基于.NET實現的DDD、CQRS與微服務架構的演示案例
【DDD/CQRS/微服務架構案例】在Ubuntu 14.04.4 LTS中運行WeText項目的服務端
基于.NET CORE微服務框架 -surging的介紹和簡單示例 （開源）
剝析surging的架構思想
基于.NET CORE微服務框架 -談談surging的服務容錯降級
我眼中的ASP.NET Core之微服務
.NET Core 事件總線,分布式事務解決方案：CAP
原文地址：http://www.cnblogs.com/sheng-jie/p/7266557.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的DDD理论学习系列（13）-- 模块的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 腾讯游戏使用Microsoft Serv
- 下一篇： Redola.Rpc 集成 Consul