最近在做電商業務中，有關商品業務改版的一些東西，後端的架構設計採用現在很流行的微服務，有關微服務的簡單概念： 微服務是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關註於完成一件任務並很好地完成該任務。在所有情況下，每 ...
最近在做電商業務中，有關商品業務改版的一些東西，後端的架構設計採用現在很流行的微服務，有關微服務的簡單概念：
微服務是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關註於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。
關於改版的業務設計，還是想嘗試 DDD 領域驅動設計，之前寫的一些相關文章，都是直接進行戰術設計，而非在戰略設計基礎上進行，所以最後可能會出現一些問題，所以這次的過程是：邊瞭解業務、邊瞭解 IDDD 書中關於戰略設計的部分，然後嘗試使用戰略設計的方式進行業務分析，最後再細分出具體的戰術設計，沒有正確的設計方案，只有合適的設計方案，排除技術之外的業務分析過程，還是蠻有意思的。
DDD 戰略建模（包含概念）：領域（Domain）、核心域、子域、界限上下文（Bounded Context）、上下文映射圖（Context Mapping）。
相關文章：
1. 業務流程
業務場景：發佈商品
業務場景就上面四個字，看起來很簡單，但其實具體分析起來，所包含的東西還是蠻多的，整個發佈商品過程，就像一個商品誕生的生命周期一樣，需要經歷各個階段和過程，直到商品正式發佈出來，並且在這個過程中，有一系列的其他概念由商品衍生出來，比如庫存、分類、品牌等等，還會有一些用戶的行為參與，比如小二的後臺審核等。
在業務分析過程中，我還是比較喜歡畫一張簡單的業務流程圖，並不一定很規範，你也可以直接手繪出來，從業務流程圖中，我們可以看到整個的業務方向，有利於我們從中找出關鍵的業務點，併進行具體分析設計。
發佈商品業務流程圖：
圖比較簡單，我們需要從添加商品到發佈商品完成的過程中，抽離出關鍵的業務點，並且這些業務點事需要在業務系統中進行設計的，發佈商品流程大概分為兩個部分：
- 商戶發佈商品：這部分內容比較多，先選擇分類（分類需要進行設計），然後填寫基本信息（根據實際的業務，有很多不同的設計，是發佈商品的核心，需要重點考慮），填寫完成之後（兩種選擇：保存草稿和發佈），在小二審核之前，需要填寫入庫單，用來更新商品庫存，然後進入小二審核階段，如果審核成功，並且商戶選擇商品上架，則代表著整個商品發佈的業務流程跑完了。
- 小二審核商品：小二根據一些規定進行審核商戶發佈的商品，這個部分人工因素很大，但發佈商品的規定一般是確定，因為是人工進行操作，所以這部分內容在業務系統設計方面體現不大。
其實，選擇分類可以歸納到填寫基本信息中，重要的是基本信息具體是什麼？這部分包含的業務是什麼？該如何設計呢？後來分析了下，除了一些商品的基本信息之外（比如標題、價格、商品詳情、商品圖片），還包含了品牌、分類、屬性（一般指的是 sku）等，像標題和價格之類的屬性一般是具體的值，後面我們在戰術設計的時候，直接把它們設計成值對象即可，但對於品牌、分類之類的對象，需要進行單獨進行設計，因為它們不是一個值所能代表的，需要進行獨立維護。
除了商品信息之外，後面就是填寫採購單用來更新商品庫存了，這部分業務內容有點像外部服務一樣，通過外部服務的一些操作，最後的結果導向商品模型，這部分類似的業務以後可能會很多，比如小二審核商品信息，也像一個外部服務一樣，不過是人為進行操作的，審核最後的結果導向商品狀態，我們可以歸納出，可以改變商品狀態的一些行為，都是需要進行考慮的業務，並且這部分業務在後面建模的時候，需要重點設計。
畫業務流程圖的目的，在於熟悉整個業務的大致流程，以及對商品生命周期的瞭解，但只是大致的表述，當你對業務理解越深的時候，業務流程圖也就會越複雜，但基本的框架是不變的，所以，在畫的業務流程圖的時候，要找出業務的不變規則，比如發佈商品肯定要填寫信息、然後小二審核等，變的業務都是在這些不變的規則之上豐富起來的，最後形成整個健全的業務系統。
2. 限界上下文
關於領域、核心域和子域的概念，相對比較容易理解，領域就是業務系統的全部，核心域就是業務系統最重要的部分，比如商品業務系統，核心域就是商品，其他相對不重要的業務部分就是子域，子域又分為支撐子域和通用子域，支撐子域用來支撐核心域，在整個領域中，可以被公用的子域，稱為通用子域。
限界上下文是一個顯式的邊界，領域模型存在這個邊界職位，領域模型把通用語言表達成軟體模型，一般在設計的時候，會把領域和限界上下文一一對應（但也不是相對的），有時候限界上下文很大，但有時候限界上下文也很小，比如一段業務描述也可以稱之為限界上下文，不管概念是怎麼定義的，只需要知道限界上下文的核心是邊界，邊界的目的就是內聚合隔離。
一張簡單的商品限界上下文圖（虛線表示領域的邊界）：
首先，在商品領域中，商品是核心域，並對應一個商品上下文，庫存被設計為一個通用子域，因為以後交易的業務場景會被用到，並對應一個庫存上下文，品牌通用子域也一樣，業務場景可能會對品牌的單獨處理（比如品牌街，這是和商品不想關的），所以設計成通用子域會相對好些，分類支撐子域和屬性子域相對複雜點，其實這裡的分類和屬性都是相對於商品而言的，你可以成為商品分類和商品屬性，獨立於商品之外，分類和屬性是沒有任何存在的業務意義的，所以，把它們設計為商品領域的支撐子域會比較好些。
另外，關於分類上下文和屬性上下文之間的關係，從上面圖中就可以看到，在業務場景中屬性依附於分類，比如在發佈商品頁面，填寫商品屬性之前需要先確定商品分類，因為不同的分類有對應不同的屬性，比如錶帶材質屬性，只有手錶分類下才會有，其實它們也可以直接合二為一，叫做分類屬性支撐子域，對應分類屬性上下文，上面說過添加屬性之前，必須先確定分類，屬性就像是分類中的一個子域，屬性其實和商品沒有直接的關係，它和商品的所有關係，必須都通過分類，並且屬性的數據維護也是如此，這個後面會有調整，再詳細說明。
分類在具體的實現中，會相對比較簡單，有點像品牌的實現，頂多和商品有一些關聯，但屬性實現相對比較複雜些，因為屬性項和屬性值都是動態的，並且屬性的展現形式也是動態的，比如一個屬性項可能對應多個屬性值，並且展現可能是組合形式的（文本+單選+下拉列表），這方便在也體現在數據存儲的時候，不過可以按照一定的格式用 json 進行存儲，展現方式也是一樣。
限界上下文就像一個手術刀，將領域一點一點的進行解剖，解剖出來的部位獨立進行實現，限界上下文的具體實現就是戰術設計，並且各個限界上下文的實現之間是相互不影響。
3. 數據模型（聚合和實體）
限界上下文讓我們明白，我們到底需要做什麼東西，接下來就是針對這些東西的具體設計和實現了，怎麼實現？就是戰術設計。
戰術建模（包含概念）：聚合（Aggregate）、實體（Entity）、值對象（Value Objects）、資源庫（Repository）、領域服務（Domain Services）、領域事件（Domain Events）、模塊（Modules）。
關於戰術設計的首要前提是聚合，後面實體和值對象等概念，都是在聚合的基礎上衍生出來的，關於聚合的概念就不多說了，但需要說明下聚合設計的註意點：
- 儘量小聚合設計：有助於減少事務的提交衝突，也有利於系統性能和可伸縮性，但不能過小，比如一個聚合只包含唯一標識和單個屬性，這種設計不合理。
- 根實體可以作為聚合根。
- 聚合邊界和真實的業務約束是一致的。
- 通過唯一標識引用其他聚合。
- 事務一致性：在一個事務中，只能修改一個聚合實例。
- 在聚合之外使用最終一致性：如果可以不在意延遲，一般用領域事件進行實現。
先簡單看下商品所包含的東西：
圖中主要說明的是商品大致包含的內容：分類、屬性和基本信息，屬性又有具體的分類，但都基於分類確定的情況下。
一張簡單的商品數據模型圖：
簡單歸納下：
- 商品（聚合根）：商品（根實體）、商品圖片（實體）、商品 sku（實體）、商品描述（實體）、商品調整紀錄（實體）
- 庫存（聚合根）：庫存（根實體）、入庫詳情（實體）
- 品牌（聚合根）：品牌（根實體）
- 分類（聚合根）：分類（根實體）、分類屬性（實體）、分類屬性值（實體）
實體中的屬性只是一些示例，並不詳細，值對象並沒有在圖中體現，因為實體的屬性都可以被設計為值對象，這部分在具體實現的時候，再詳細進行考慮，聚合根和實體、聚合根和聚合根之間的關係用箭頭進行表示了。
關於分類和屬性，在限界上下文設計的時候，被分開設計了，但後來想了一下，還是設計成一個比較好，分類作為聚合根，分類屬性和分類屬性值作為衍生出來的實體。
關於數據模型圖，就不詳細說明瞭，內容都在上面的圖中，況且現在還不是很完善，後面可能還會進行調整。
大概就紀錄這些。
