這種方法是內(nèi)網(wǎng)中的一篇文章，我覺得很有實踐意義，就利用自己的理解重新梳理一下。

當(dāng)我們拿到一個需求，從小需求到項目再到新系統(tǒng)的搭建，應(yīng)該都是有一套方法論可以指導(dǎo)落地。如果按照DDD的方式來落地架構(gòu)的話，一般系統(tǒng)可以分成三層，從內(nèi)到外分別是領(lǐng)域模型層、領(lǐng)域服務(wù)層、應(yīng)用服務(wù)層，可以對外接口還會有一層，例如微服務(wù)接口，web接口等。那么我們需要做的就是將需求轉(zhuǎn)換成上面的層級結(jié)構(gòu)。

需求分解

需求分解的目的是得到用例(User Case)，在互聯(lián)網(wǎng)企業(yè)中技術(shù)得到的往往是一個PRD，是對一個需求的流程描述，屬于一個比較粗粒度的描敘，只是一個主干流程，沒有細(xì)化到一個個用例，也么有對于異常情況進(jìn)行描敘。

邊界劃分

邊界劃分是按照一定規(guī)則與約束將User Case涉及的功能劃分到不同的域，可以是不同的系統(tǒng)，也可以是同一個系統(tǒng)中的不同的域中。

一個沒有任何規(guī)則約束的隨意設(shè)計會產(chǎn)生一些無法理解的整體含義且很難維護(hù)的系統(tǒng)。

邊界劃分可以利用單一職責(zé)作規(guī)則為主要的約束，但是職責(zé)并不是一個太好量化的東西，在之前如何編寫類中思考了一些方法。另外《UML和應(yīng)用模式》中的GRASP也可以用來輔助劃分，引用內(nèi)網(wǎng)一篇文章的圖片

用例拆解

當(dāng)已經(jīng)劃分好邊界，那就可以對每個用例進(jìn)行分解，分解成每個小的步驟，然后對每個步驟進(jìn)行聚類分組，形成如下的層級結(jié)構(gòu)：Commond -> Phase -> Step。

模型的沉淀

用例拆解將每個用戶拆解成了一個數(shù)據(jù)執(zhí)行的pipeline，但是系統(tǒng)中的模型業(yè)務(wù)語義表達(dá)能力不強(qiáng)，因此需要不斷的梳理出系統(tǒng)中重復(fù)的地方，然后進(jìn)行能力的下沉，找到這些邏輯真正的歸屬。

總結(jié)

利用上面幾步基本可以完成需求到架構(gòu)的落地，尤其是用例的拆解與模型的沉底，實踐起來比較容易。