架構設計-商品子產品的領域驅動設計思路及實作

開頭先說兩句

小刀部落格: https://www.lixiang.red

歡迎留言一起讨論

項目背景

因脫敏關系,這裡面三個角色就用A,B,C來代替,可以抽象了解為, A 是需求發起方,B是平台營運方, C是資源提供方. 代入今天的商品子產品,就是A 要商品, C能提供商品.B 來進行中間的邏輯判斷能否提供對應的商品

設計之初及一些方法

在給本文起标題的時候猶豫了下,是寫架構設計還是寫DDD呢,後來想了一想,這個項目也是在嘗試DDD,用的還不是很成熟,就還是寫了架構設計.

以往我們說想要設計個什麼東西的時候,然後就開始想要建什麼表,表裡面有什麼字段,然後開始打開navicat/datagrip建表,然後寫代碼對表進行增删改查,然後交工

那麼現在我們來一起換種方法思考下,在小刀看來,架構設計分兩部分,一部分是業務架構,一部分是技術架構.

技術架構

對開發人員來說,技術架構不是很難的事,因為很多可以開箱即用的東西,如spring全家桶. 對于項目初期要求快速上線快速疊代,是以基本上也沒什麼個性化的配置調優,用預設的先跑起來就行, springboot+springmvc+mybatis+redis 這一套估計大家都可以搭一個項目環境開發起來,我們的這個項目也是基于這個技術選型之下

業務架構

這個是今天的重點,我們先不談表,先聊業務,然後一步步的往下走

提取語言關鍵詞

然後提取出各個關鍵詞,從上述項目背景中,我們可以提取出以下幾個概念:

A,B,C,商品,比對規則.

從這些關鍵詞中,我們再進一步劃分,有業務相關,有領域(基礎)相關的

業務關鍵詞有: A,B,C

領域關鍵詞有: 商品,比對規則

然後我們可以用這些關鍵詞去組織語言重新描述這個事情:

1. A 釋出了對 商品 的需求
   1. C 提供了 商品 的資訊
   2. B 使用 比對規則 驗證 C 的 商品 是否滿足 A 需求的 商品

這時候,在第3句中已經産生了歧義,因為C 提供的 和 A 釋出需求使用的實際上是兩個不同的實體. 比如: 小刀說,我想買個16G的iphone8 , 京東說我有,3000塊,淘寶說我有: 2000塊. 從這看來,這是兩個不同的實體

是以我們重象出一個新領域概念:産品,同時修改語言為:

1. A 釋出了一個 産品 的需求
2. C 提供了一些 商品 的資訊
3. B 使用 比對規則 驗證 C 的 商品 是否滿足 A 的 産品 需求

這樣一來,隻有比對規則是一個黑盒子了,但這塊是業務邏輯,在架構設計之初,可以不做太多考慮,用一個設計模式中的模闆模式定義一個方法,以後再實作.

深入業務場景

目前為止的業務架構設計已提取了基本關鍵關鍵詞元素,後續的場景就是以這些元素為主角去完成我們現實中的需求,這裡和測試用例的設計比較像了,何為深入業務場景,就是和領域内專家多讨論,從讨論中提取業務場景模型,然後用我們提取出來語言關鍵詞描述清這些場景.

當然不是每個公司都請得起領域專家,更多的需要設計者自己去思考業務,我們自己即模拟開發人員,又模拟業務人員.還是以上述小刀買 16G的iphone8為例, 京東說我雖然貴,但是我送充電器,送耳機,送膜. 淘寶說我最便宜,隻有裸機一個. 同時要注意的是,充電器,耳機,膜這些本身也是單獨的商品,也就是說,在某些場景下,商品并不是最小銷售機關. 這些商品的組合,或者這些商品衍生出的一個新概念才是最小銷售機關,我們可以稱之為: sku

通過上述場景我們提煉出了 sku 這個關鍵字,還有很多場景可以深入,比如小刀需要的是一批手機, 然後京東有一部分, 淘寶有一部分,這種場景下可以再提煉出類似于 拆包 這樣的關鍵詞

強化領域概念,劃分上下界

經過我們的初步分析的深入提煉,我們現在共記得到了如下幾個關鍵字:

業務: A,B,C 領域: 産品,商品,SKU,比對規則

本段我們就領域中的概念繼續提煉

一個産品對應多個商品,一個商品對應多個sku ,sku既是最小銷售機關,也是最終和業務域産生業務關聯的實體.是以,别的領域想要擷取商口域的相關資訊,都要傳入一個sku實體.最後我們可以得到這樣一個圖

最後的建表工作