最近在做電商業務中，有關商品業務改版的一些東西，後端的架構設計採用現在很流行的微服務，有關微服務的簡單概念：
微服務是一種架構風格，乙個大型複雜軟體應用由乙個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著乙個小的業務能力。業務場景：發布商品業務場景就上面四個字，看起來很簡單，但其實具體分析起來，所包含的東西還是蠻多的，整個發布商品過程，就像乙個商品誕生的生命週期一樣，需要經歷各個階段和過程，直到商品正式發布出來，並且在這個過程中，有一系列的其他概念由商品衍生出來，比如庫存、分類、品牌等等，還會有一些使用者的行為參與，比如小二的後台審核等。
發布商品業務流程圖：
圖比較簡單，我們需要從新增商品到發布商品完成的過程中，抽離出關鍵的業務點，並且這些業務點事需要在業務系統中進行設計的，發布商品流程大概分為兩個部分：
商戶發布商品：這部分內容比較多，先選擇分類（分類需要進行設計），然後填寫基本資訊（根據實際的業務，有很多不同的設計，是發布商品的核心，需要重點考慮），填寫完成之後（兩種選擇：儲存草稿和發布），在小二審核之前，需要填寫入庫單，用來更新商品庫存，然後進入小二審核階段，如果審核成功，並且商戶選擇商品上架，則代表著整個商品發布的業務流程跑完了。
小二審核商品：小二根據一些規定進行審核商戶發布的商品，這個部分人工因素很大，但發布商品的規定一般是確定，因為是人工進行操作，所以這部分內容在業務系統設計方面體現不大。
其實，選擇分類可以歸納到填寫基本資訊中，重要的是基本資訊具體是什麼？這部分包含的業務是什麼？該如何設計呢？後來分析了下，除了一些商品的基本資訊之外（比如標題、**、商品詳情、商品），還包含了品牌、分類、屬性（一般指的是 sku）等，像標題和**之類的屬性一般是具體的值，後面我們在戰術設計的時候，直接把它們設計成值物件即可，但對於品牌、分類之類的物件，需要進行單獨進行設計，因為它們不是乙個值所能代表的，需要進行獨立維護。
除了商品資訊之外，後面就是填寫採購單用來更新商品庫存了，這部分業務內容有點像外部服務一樣，通過外部服務的一些操作，最後的結果導向商品模型，這部分類似的業務以後可能會很多，比如小二審核商品資訊，也像乙個外部服務一樣，不過是人為進行操作的，審核最後的結果導向商品狀態，我們可以歸納出，可以改變商品狀態的一些行為，都是需要進行考慮的業務，並且這部分業務在後面建模的時候，需要重點設計。
畫業務流程圖的目的，在於熟悉整個業務的大致流程，以及對商品生命週期的了解，但只是大致的表述，當你對業務理解越深的時候，業務流程圖也就會越複雜，但基本的框架是不變的，所以，在畫的業務流程圖的時候，要找出業務的不變規則，比如發布商品肯定要填寫資訊、然後小二審核等，變的業務都是在這些不變的規則之上豐富起來的，最後形成整個健全的業務系統。
關於領域、核心域和子域的概念，相對比較容易理解，領域就是業務系統的全部，核心域就是業務系統最重要的部分，比如商品業務系統，核心域就是商品，其他相對不重要的業務部分就是子域，子域又分為支撐子域和通用子域，支撐子域用來支撐核心域，在整個領域中，可以被公用的子域，稱為通用子域。
限界上下文是乙個顯式的邊界，領域模型存在這個邊界職位，領域模型把通用語言表達成軟體模型，一般在設計的時候，會把領域和限界上下文一一對應（但也不是相對的），有時候限界上下文很大，但有時候限界上下文也很小，比如一段業務描述也可以稱之為限界上下文，不管概念是怎麼定義的，只需要知道限界上下文的核心是邊界，邊界的目的就是內聚合隔離。
一張簡單的商品限界上下文圖（虛線表示領域的邊界）：
首先，在商品領域中，商品是核心域，並對應乙個商品上下文，庫存被設計為乙個通用子域，因為以後交易的業務場景會被用到，並對應乙個庫存上下文，品牌通用子域也一樣，業務場景可能會對品牌的單獨處理（比如品牌街，這是和商品不想關的），所以設計成通用子域會相對好些，分類支撐子域和屬性子域相對複雜點，其實這裡的分類和屬性都是相對於商品而言的，你可以成為商品分類和商品屬性，獨立於商品之外，分類和屬性是沒有任何存在的業務意義的，所以，把它們設計為商品領域的支撐子域會比較好些。
另外，關於分類上下文和屬性上下文之間的關係，從上面圖中就可以看到，在業務場景中屬性依附於分類，比如在發布商品頁面，填寫商品屬性之前需要先確定商品分類，因為不同的分類有對應不同的屬性，比如錶帶材質屬性，只有手錶分類下才會有，其實它們也可以直接合二為一，叫做分類屬性支撐子域，對應分類屬性上下文，上面說過新增屬性之前，必須先確定分類，屬性就像是分類中的乙個子域，屬性其實和商品沒有直接的關係，它和商品的所有關係，必須都通過分類，並且屬性的資料維護也是如此，這個後面會有調整，再詳細說明。
分類在具體的實現中，會相對比較簡單，有點像品牌的實現，頂多和商品有一些關聯，但屬性實現相對比較複雜些，因為屬性項和屬性值都是動態的，並且屬性的展現形式也是動態的，比如乙個屬性項可能對應多個屬性值，並且展現可能是組合形式的（文字+單選+下拉列表），這方便在也體現在資料儲存的時候，不過可以按照一定的格式用 json 進行儲存，展現方式也是一樣。
限界上下文就像乙個手術刀，將領域一點一點的進行解剖，解剖出來的部位獨立進行實現，限界上下文的具體實現就是戰術設計，並且各個限界上下文的實現之間是相互不影響。
限界上下文讓我們明白，我們到底需要做什麼東西，接下來就是針對這些東西的具體設計和實現了，怎麼實現？就是戰術設計。
戰術建模（包含概念）：聚合（aggregate）、實體（entity）、值物件（value objects）、資源庫（repository）、領域服務（domain services）、領域事件（domain events）、模組（modules）。
關於戰術設計的首要前提是聚合，後面實體和值物件等概念，都是在聚合的基礎上衍生出來的，關於聚合的概念就不多說了，但需要說明下聚合設計的注意點：
先簡單看下商品所包含的東西：
圖中主要說明的是商品大致包含的內容：分類、屬性和基本資訊，屬性又有具體的分類，但都基於分類確定的情況下。
一張簡單的商品資料模型圖：
簡單歸納下：
庫存（聚合根）：庫存（根實體）、入庫詳情（實體）
品牌（聚合根）：品牌（根實體）
分類（聚合根）：分類（根實體）、分類屬性（實體）、分類屬性值（實體）
實體中的屬性只是一些示例，並不詳細，值物件並沒有在圖中體現，因為實體的屬性都可以被設計為值物件，這部分在具體實現的時候，再詳細進行考慮，聚合根和實體、聚合根和聚合根之間的關係用箭頭進行表示了。
關於分類和屬性，在限界上下文設計的時候，被分開設計了，但後來想了一下，還是設計成乙個比較好，分類作為聚合根，分類屬性和分類屬性值作為衍生出來的實體。
關於資料模型圖，就不詳細說明了，內容都在上面的圖中，況且現在還不是很完善，後面可能還會進行調整。
大概就紀錄這些。
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...