1. 業務流程

業務場景：發布商品

業務場景就上面四個字，看起來很簡單，但其實具體分析起來，所包含的東西還是蠻多的，整個發布商品過程，就像一個商品誕生的生命周期一樣，需要經歷各個階段和過程，直到商品正式發布出來，并且在這個過程中，有一系列的其他概念由商品衍生出來，比如庫存、分類、品牌等等，還會有一些用戶的行為參與，比如小二的后臺審核等。

在業務分析過程中，我還是比較喜歡畫一張簡單的業務流程圖，并不一定很規范，你也可以直接手繪出來，從業務流程圖中，我們可以看到整個的業務方向，有利于我們從中找出關鍵的業務點，并進行具體分析設計。

發布商品業務流程圖：

圖比較簡單，我們需要從添加商品到發布商品完成的過程中，抽離出關鍵的業務點，并且這些業務點事需要在業務系統中進行設計的，發布商品流程大概分為兩個部分：

商戶發布商品：這部分內容比較多，先選擇分類(分類需要進行設計)，然后填寫基本信息(根據實際的業務，有很多不同的設計，是發布商品的核心，需要重點考慮)，填寫完成之后(兩種選擇：保存草稿和發布)，在小二審核之前，需要填寫入庫單，用來更新商品庫存，然后進入小二審核階段，如果審核成功，并且商戶選擇商品上架，則代表著整個商品發布的業務流程跑完了。

小二審核商品：小二根據一些規定進行審核商戶發布的商品，這個部分人工因素很大，但發布商品的規定一般是確定，因為是人工進行操作，所以這部分內容在業務系統設計方面體現不大。

其實，選擇分類可以歸納到填寫基本信息中，重要的是基本信息具體是什么？這部分包含的業務是什么？該如何設計呢？后來分析了下，除了一些商品的基本信息之外(比如標題、價格、商品詳情、商品圖片)，還包含了品牌、分類、屬性(一般指的是 sku)等，像標題和價格之類的屬性一般是具體的值，后面我們在戰術設計的時候，直接把它們設計成值對象即可，但對于品牌、分類之類的對象，需要進行單獨進行設計，因為它們不是一個值所能代表的，需要進行獨立維護。

除了商品信息之外，后面就是填寫采購單用來更新商品庫存了，這部分業務內容有點像外部服務一樣，通過外部服務的一些操作，最后的結果導向商品模型，這部分類似的業務以后可能會很多，比如小二審核商品信息，也像一個外部服務一樣，不過是人為進行操作的，審核最后的結果導向商品狀態，我們可以歸納出，可以改變商品狀態的一些行為，都是需要進行考慮的業務，并且這部分業務在后面建模的時候，需要重點設計。

畫業務流程圖的目的，在于熟悉整個業務的大致流程，以及對商品生命周期的了解，但只是大致的表述，當你對業務理解越深的時候，業務流程圖也就會越復雜，但基本的框架是不變的，所以，在畫的業務流程圖的時候，要找出業務的不變規則，比如發布商品肯定要填寫信息、然后小二審核等，變的業務都是在這些不變的規則之上豐富起來的，最后形成整個健全的業務系統。

2. 限界上下文

關于領域、核心域和子域的概念，相對比較容易理解，領域就是業務系統的全部，核心域就是業務系統最重要的部分，比如商品業務系統，核心域就是商品，其他相對不重要的業務部分就是子域，子域又分為支撐子域和通用子域，支撐子域用來支撐核心域，在整個領域中，可以被公用的子域，稱為通用子域。

限界上下文是一個顯式的邊界，領域模型存在這個邊界職位，領域模型把通用語言表達成軟件模型，一般在設計的時候，會把領域和限界上下文一一對應(但也不是相對的)，有時候限界上下文很大，但有時候限界上下文也很小，比如一段業務描述也可以稱之為限界上下文，不管概念是怎么定義的，只需要知道限界上下文的核心是邊界，邊界的目的就是內聚合隔離。

一張簡單的商品限界上下文圖(虛線表示領域的邊界)：

首先，在商品領域中，商品是核心域，并對應一個商品上下文，庫存被設計為一個通用子域，因為以后交易的業務場景會被用到，并對應一個庫存上下文，品牌通用子域也一樣，業務場景可能會對品牌的單獨處理(比如品牌街，這是和商品不想關的)，所以設計成通用子域會相對好些，分類支撐子域和屬性子域相對復雜點，其實這里的分類和屬性都是相對于商品而言的，你可以成為商品分類和商品屬性，獨立于商品之外，分類和屬性是沒有任何存在的業務意義的，所以，把它們設計為商品領域的支撐子域會比較好些。

另外，關于分類上下文和屬性上下文之間的關系，從上面圖中就可以看到，在業務場景中屬性依附于分類，比如在發布商品頁面，填寫商品屬性之前需要先確定商品分類，因為不同的分類有對應不同的屬性，比如表帶材質屬性，只有手表分類下才會有，其實它們也可以直接合二為一，叫做分類屬性支撐子域，對應分類屬性上下文，上面說過添加屬性之前，必須先確定分類，屬性就像是分類中的一個子域，屬性其實和商品沒有直接的關系，它和商品的所有關系，必須都通過分類，并且屬性的數據維護也是如此，這個后面會有調整，再詳細說明。

分類在具體的實現中，會相對比較簡單，有點像品牌的實現，頂多和商品有一些關聯，但屬性實現相對比較復雜些，因為屬性項和屬性值都是動態的，并且屬性的展現形式也是動態的，比如一個屬性項可能對應多個屬性值，并且展現可能是組合形式的(文本+單選+下拉列表)，這方便在也體現在數據存儲的時候，不過可以按照一定的格式用 json 進行存儲，展現方式也是一樣。

限界上下文就像一個手術刀，將領域一點一點的進行解剖，解剖出來的部位獨立進行實現，限界上下文的具體實現就是戰術設計，并且各個限界上下文的實現之間是相互不影響。

3. 數據模型(聚合和實體)

限界上下文讓我們明白，我們到底需要做什么東西，接下來就是針對這些東西的具體設計和實現了，怎么實現？就是戰術設計。

戰術建模(包含概念)：聚合(Aggregate)、實體(Entity)、值對象(Value Objects)、資源庫(Repository)、領域服務(Domain Services)、領域事件(Domain Events)、模塊(Modules)。

關于戰術設計的首要前提是聚合，后面實體和值對象等概念，都是在聚合的基礎上衍生出來的，關于聚合的概念就不多說了，但需要說明下聚合設計的注意點：

盡量小聚合設計：有助于減少事務的提交沖突，也有利于系統性能和可伸縮性，但不能過小，比如一個聚合只包含唯一標識和單個屬性，這種設計不合理。

根實體可以作為聚合根。

聚合邊界和真實的業務約束是一致的。

通過唯一標識引用其他聚合。

事務一致性：在一個事務中，只能修改一個聚合實例。

在聚合之外使用最終一致性：如果可以不在意延遲，一般用領域事件進行實現。

先簡單看下商品所包含的東西：

圖中主要說明的是商品大致包含的內容：分類、屬性和基本信息，屬性又有具體的分類，但都基于分類確定的情況下。

一張簡單的商品數據模型圖：

簡單歸納下：

商品(聚合根)：商品(根實體)、商品圖片(實體)、商品 sku(實體)、商品描述(實體)、商品調整紀錄(實體)

庫存(聚合根)：庫存(根實體)、入庫詳情(實體)

品牌(聚合根)：品牌(根實體)

分類(聚合根)：分類(根實體)、分類屬性(實體)、分類屬性值(實體)

實體中的屬性只是一些示例，并不詳細，值對象并沒有在圖中體現，因為實體的屬性都可以被設計為值對象，這部分在具體實現的時候，再詳細進行考慮，聚合根和實體、聚合根和聚合根之間的關系用箭頭進行表示了。

關于分類和屬性，在限界上下文設計的時候，被分開設計了，但后來想了一下，還是設計成一個比較好，分類作為聚合根，分類屬性和分類屬性值作為衍生出來的實體。

關于數據模型圖，就不詳細說明了，內容都在上面的圖中，況且現在還不是很完善，后面可能還會進行調整。

大概就紀錄這些。

本文轉自田園里的蟋蟀博客園博客，原文鏈接：http://www.cnblogs.com/xishuai/p/ddd-product-design.html，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的商品领域ddd_DDD 领域驱动设计-商品建模之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。