在DDD的正式實施開始中，我們首先應該進行需求調研，在需求調研的過程中，我們應該可以接觸到這個需求各個層面的相關人員：產品設計，開發(fā)，業(yè)務代表，實施人員等等。當進行完初步的需求調研，我們可以形成對應的產品文檔和產品交互設計等等，以上都是相對成熟的設計方法和流程，所以不再復述。在進行完上述環(huán)節(jié)后，我們大體上可以進行系統(tǒng)的設計階段了，那么在這個階段，我們應該如何進行我們第一步操作？
對于設計一個系統(tǒng)，第一步并不是劃分什么微服務，而是應該先組織一個設計活動，我們將之稱為：事件風暴。
事件風暴的參與者需要組織和這個系統(tǒng)相關方盡可能的參加：需求代表，相關業(yè)務操作人員，產品設計人員，以及開發(fā)代表（應用架構師），測試代表，實施人員等等。
當有了以上人員的參加，我們就可以開始事件風暴，
事件風暴的第一個活動就是大家集中對用例進行收集（有的已經在產品設計階段完成了部分）和分析,或者在組織事件風暴活動之前，我們已經完成了初步的用例收集。用例收集的部分用例大體如下表格所示（圖例所示是一個支付系統(tǒng)的設計過程）：
用例基本上都是基于現(xiàn)實業(yè)務流程，面向不同的業(yè)務和應用和使用者，都有不同的處理流程和方式。
在收集完畢用例后，我們可以通過每一個用例按照用例主體，用例動作，以及被操作實體，繼續(xù)對每一個用例進行分析和分解。其實也就是我們中學語文中經常對 一句話找出其主謂賓類似。承接上圖就有了以下這些劃分：
在被操作的實體對象中，如果我們將這些實體進行相應的歸類，比如：
? ? ? ? ? ? ? ? ? ? 對賬文件，對賬批次 ，對賬單，調整單一類，畢竟貌似這幾個都和對賬有點關系? ?
? ? ? ? ? ? ? ? ? ? 支付訂單 一類 這個感覺相對獨立
? ? ? ? ? ? ? ? ? ? 商戶賬戶? 這個感覺更加獨立，也歸為一類
? ? ? 通過將實體對象的歸類，我們就可以認為一類近似的實體，可以歸屬于一類領域。那么首先我們要先回答一個問題：我們?yōu)槭裁匆獎澐诸I域，一個大而全的系統(tǒng)不好嗎？
? ? ? 因為系統(tǒng)解決的一定是我們上面所列的流程和用例，所以系統(tǒng)可以說是面向的就是業(yè)務和流程，而領域的劃分就是跨越流程，沉淀出相應的服務，服務的主體就應該是基于領域。而且一旦我們通過沉淀了服務，我們服務就超越了流程，可以支撐更多的業(yè)務和產品的創(chuàng)新，而且在未來業(yè)務發(fā)生變化時，應對變化的不是系統(tǒng)，而是服務，這樣增強了我們整個系統(tǒng)的可擴展性。
? ? ? 那么上面的示例 我們至少可以劃分這樣三個域：賬戶域，支付訂單域，對賬域等等。然后我們可以在這些領域中，我們可以找尋其中的核心域和支撐域，以及通用域。那什么是核心域？就需要回答這個問題：這個系統(tǒng)是通過什么東西提供了核心業(yè)務服務是什么？這個不是技術問題，而是一個業(yè)務問題。如果回答了這個問題，那么這個問題所涉及的對象就是核心域。至于支撐域和通用域，顧名思義可以了解到，就是為了支撐核心域的其他業(yè)務域為支撐域（不通用）；通用域則是在全局范圍內，都需要依賴的領域，比如權限。確定整個系統(tǒng)的核心域是一個經驗主義的過程個，核心域的劃分沒有絕對的公式可以套用。因為商業(yè)模式的不同會導致核心域劃分結果的不同。有的公司核心域可能在客戶服務，有的可能在產品質量，有的可能在物流。在公司領域細分、建立領域模型和系統(tǒng)建設時，我們需要結合公司戰(zhàn)略重點和商業(yè)模式，找到核心域了，且應該重點關注核心域。
? ? ?既然在不同的商業(yè)場景下，核心域就是不一樣的，比如筆者曾經參與過兩套支付系統(tǒng)的建設，很多場景都是雷同的（如上圖），現(xiàn)今回想起來一套核心域是訂單，另一套則是賬戶。因為雖然支付系統(tǒng)都有訂單，但由于其中一個支付系統(tǒng)后面不光只是支付收單，還涉及到理財，錢包，以及海外貨幣匯兌（海外牌照）等等業(yè)務，所以這個系統(tǒng)的核心域自然是賬戶體系。 但另一個支付系統(tǒng)就是簡單的收集支付訂單，核對流水，最后把整個訂單金額去向進行留存歸檔即可（因為不涉及賬戶資金劃撥），所以核心域就是支付訂單。
? ? ? 當我們一旦明確了核心域，我們系統(tǒng)建設應該將核心域的建設排在首位，最好是有絕對的掌控能力和自主研發(fā)能力，如果資源實在有限的話，可以在支撐域或者通用域上想想辦法，暫時采用外購的方式也未嘗不可。所以當我們需要外包時，我們應該盡可能的外包非核心域的東西，盡可能的選擇其他部分。（當然如何控制外包的質量，后面再談）
