開頭先說兩句
小刀博客: https://www.lixiang.red
歡迎留言一塊兒討論java
項目背景
因脫敏關係,這裏面三個角色就用A,B,C來代替,能夠抽象理解爲, A 是需求發起方,B是平臺運營方, C是資源提供方. 代入今天的商品模塊,就是A 要商品, C能提供商品.B 來進行中間的邏輯判斷可否提供對應的商品redis
設計之初及一些方法
在給本文起標題的時候猶豫了下,是寫架構設計仍是寫DDD呢,後來想了一想,這個項目也是在嘗試DDD,用的還不是很成熟,就仍是寫了架構設計.spring
以往咱們說想要設計個什麼東西的時候,而後就開始想要建什麼表,表裏面有什麼字段,而後開始打開navicat/datagrip建表,而後寫代碼對錶進行增刪改查,而後交工設計模式
那麼如今咱們來一塊兒換種方法思考下,在小刀看來,架構設計分兩部分,一部分是業務架構,一部分是技術架構.springboot
技術架構
對開發人員來講,技術架構不是很難的事,由於不少能夠開箱即用的東西,如spring全家桶. 對於項目初期要求快速上線快速迭代,因此基本上也沒什麼個性化的配置調優,用默認的先跑起來就行, springboot+springmvc+mybatis+redis 這一套估計你們均可以搭一個項目環境開發起來,咱們的這個項目也是基於這個技術選型之下微信
業務架構
這個是今天的重點,咱們先不談表,先聊業務,而後一步步的往下走mybatis
提取語言關鍵詞
而後提取出各個關鍵詞,從上述項目背景中,咱們能夠提取出如下幾個概念:架構
A,B,C,商品,匹配規則.mvc
從這些關鍵詞中,咱們再進一步劃分,有業務相關,有領域(基礎)相關的iphone
業務關鍵詞有: A,B,C
領域關鍵詞有: 商品,匹配規則
而後咱們能夠用這些關鍵詞去組織語言從新描述這個事情:
A 發佈了對 商品 的需求
C 提供了 商品 的信息
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實體.最後咱們能夠獲得這樣一個圖
圖只是簡單示意了總體結構,其實還有repo , spec 等領域概念沒有畫出來,小夥伴們能夠對照本身的模塊,設計出本身的結構圖
最後的建表工做
說了這麼多,終於到建表這一步了,真正到這一步時,其實沒多少要說的,對每一個實體建張表,而後設置對應的字段屬性,而後寫增刪改查給領域調用, 對於設計,你有什麼見解? 歡迎各位小夥伴留言一塊兒討論
本文分享自微信公衆號 - java技術大本營（java-ideashare）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。