這種方法是內網中的一篇文章，我覺得很有實踐意義，就利用自己的理解重新梳理一下。
當我們拿到一個需求，從小需求到項目再到新系統的搭建，應該都是有一套方法論可以指導落地。如果按照DDD的方式來落地架構的話，一般系統可以分成三層，從內到外分別是領域模型層、領域服務層、應用服務層，可以對外接口還會有一層，例如微服務接口，web接口等。那麼我們需要做的就是將需求轉換成上面的層級結構。
需求分解
需求分解的目的是得到用例(User Case)，在互聯網企業中技術得到的往往是一個PRD，是對一個需求的流程描述，屬於一個比較粗粒度的描敘，只是一個主幹流程，沒有細化到一個個用例，也麼有對於異常情況進行描敘。
邊界劃分
邊界劃分是按照一定規則與約束將User Case涉及的功能劃分到不同的域，可以是不同的系統，也可以是同一個系統中的不同的域中。
一個沒有任何規則約束的隨意設計會產生一些無法理解的整體含義且很難維護的系統。
邊界劃分可以利用單一職責作規則爲主要的約束，但是職責並不是一個太好量化的東西，在之前如何編寫類中思考了一些方法。另外《UML和應用模式》中的GRASP也可以用來輔助劃分，引用內網一篇文章的圖片
用例拆解
當已經劃分好邊界，那就可以對每個用例進行分解，分解成每個小的步驟，然後對每個步驟進行聚類分組，形成如下的層級結構：Commond -> Phase -> Step。
模型的沉澱
用例拆解將每個用戶拆解成了一個數據執行的pipeline，但是系統中的模型業務語義表達能力不強，因此需要不斷的梳理出系統中重複的地方，然後進行能力的下沉，找到這些邏輯真正的歸屬。
總結
利用上面幾步基本可以完成需求到架構的落地，尤其是用例的拆解與模型的沉底，實踐起來比較容易。