領域模型的技術實踐能給我們什么啟發?
編輯導語:對于互聯網軟件開發流程中,領域模型的技術實踐比較適用于當前的開發人員,同時很多思維也適用于產品人員,它更加傾向于給大家傳遞良好的思路與習慣。作者總結梳理了自己的個人經驗,與你分享。
前幾期的文章,主要給大家描述了領域模型的概念和用法。針對互聯網軟件開發流程中,領域模型技術實踐比較傾向于給大家傳遞良好的編程習慣和思路,適用于當前的開發人員。
但我自己在總結梳理以及結合個人經驗的同時發現,這里面其實也有很多思維同樣適用于產品人員,分享出來希望給大家一點啟發。
一、如何開始調研設計產品
當我們置身于一個陌生業務領域時,看不清業務全貌甚至存在很多潛在場景,困惑和不知所措是大多數的人狀態。
針對這種情形,領域模型中關于研發人員從哪里敲下第一行代碼的講解能帶給我們一些啟發。常規來說,一般在研發前會進行設計,無論是數據庫還是時序交互,一般都是由下而上,打好地基再來搭建上層建筑。
(領域模型技術實踐提倡的開發習慣)
但把我們自己放進真實的工作場景中,其實會發現即使業務本身比較明確,在設計的時候考慮數據庫結構的字段,業務間的數據交互等等時還是會有一些困惑。這種工作由下而上的方式很多時候會演變成為了設計而設計。
所以我們會建議大家先從確定性的功能業務開始寫代碼,當所有確定性的東西完成后模糊的東西會更加清晰,在這個過程中我們底層的結構會自然清晰。
對于這種思維方式,我覺得同樣適用于產品工作。任何業務領域中從基本或確定性場景出發,慢慢拓展,能夠高效的幫你盡快熟悉陌生業務領域。
在這里我們拿電商購物的場景舉例,我們從用戶購買這個核心場景出發。在梳理時,盡量先補全業務全貌,不要急于去思考細節。
從確定性業務場景出發,我們能比較快速的補全主流程的業務線。再在各個流程業務間去考慮其他相關因素,慢慢補全整個業務全貌。
(學會用業務滋養中臺)
這種方式能比較快的幫助我們探索一個陌生業務領域,但在梳理的過程中一定要從主干出發,切勿一開始就深究細節。用業務本身幫助完善我們的業務領域模型。
二、學會拆分產品形成邊界
之前我們有提到一個概念叫業務領域模型,在實際操作過程中我們的業務領域模型需要區分核心域和公共域。
核心域其實就是業務的核心本質,不同于公共域消息、權限等比較常見的業務。因此我們需要對我們的領域模型以及產品進行拆分,從而形成邊界。
拆分的原則其實就是遵從業務本身,圍繞業務能力進行組織。這里我們還用之前的乘車業務舉例。
可以比較清晰的看到,拆分的結果分為核心和公共兩個部分。針對大多數的微服務架構,就是根據這樣的業務模式進行拆分。拆的過細或者太粗對于微服務和業務領域都沒有太大價值,所以還是要以業務本身為準。
大家也可以根據整個服務的拆分,自己去梳理整體的業務流程。
三、用資產的眼光去看待產品并保持演進
不管是業務領域模型還是產品本身,一定都存在一直迭代的過程。對于迭代,我們需要承認的是產品本身的不完美和缺陷。但這也是任何產品自身但宿命和現實,世界上根本不存在完美的事物。
對于現有的代碼和業務領域模型,我們一定要用資產的眼光去看待。資產本身會有一個欠債的概念,當我們的代碼在實現過程中沒有真正考慮復用性,只是為了實現需求,本身其實就相當于欠下了無形的債務。
當業務擴張時,會發現我們的代碼完全支持不了業務本身,這個時候其實就是還債的過程,對于業務領域模型也是同樣的道理。
任何過度設計,缺陷設計下的弊端總有一天會暴露出來,欠下的債務也一定需要償還。好了,這次的領域模型講解就到這里,對于領域模型我也梳理了大綱,有興趣的朋友可以看看。
領域模型技術實踐個人梳理:
本文由 @都市擺渡人 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
學習了
請問前幾期文章在哪里呢?
可以來公眾號看:都市擺渡人