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