引言
有一個認可度比較高的對於軟件系統架構的定義：職責明確的模塊或者組件、關聯關係、約束和指導原則。如下圖所示：
當我們通過需求分析得到了業務的實例化規則以及領域模型之後，接下來就是進行系統的架構，按照上面對架構的定義，其中比較重要的步驟就是對系統進行拆分與集成。
拆分的好處
將系統拆細之後主要可以簡化認知與增加複用。
簡化認知：將系統拆細後一次只需要理解少量的概念，在一個特定的範圍內工作。在工作中與其他域的同事進行合作的時候很難的地方就是概念的理解，面對一個新的名稱或者同一個名稱的不同用法（解釋）時往往難以短時間理解，因此在系統設計中沒有必要不要輕易的新增概念。
增加複用：當把系統拆細之後，每個子系統都有自己特定的問題域，可以屏蔽一些特定的依賴（隔離了變化），因此可以增加複用度。
拆分的粒度
在目前的工作中，根據粒度的不同從大到小可以拆分成應用、模塊（jar包）、包、類等幾種。
子域與應用
拆分的原則與過程
拆分最重要的原則是：領域體現的業務能力，也就是說拆分出來的子系統有沒有可能成爲一個獨立的業務。這裏獨立的業務更多針對的是應用級別的，當然也可以暫時把子域放到一個應用中，不過需要具備獨立出來的條件。就目前工作中較少遇到可以獨立應用的機會。
拆分的過程：根據業務的流程，對每個業務流程進行分析，看該業務流程是否符合獨立業務的條件（除了在目前的業務場景下使用，還有沒有可能爲其他業務使用）。
集成
集成是由雙方組成的，依賴方與被依賴方，作爲被依賴方，也就是服務提供方，主要有兩種方式，一種是產品化方式，不提供業務定製化能力，提供的是標準服務，例如支付寶的支付服務，短信的發送服務等；另外一種是供應商方式，根據客戶的需求來定製一些服務接口，在業務部門，一般都是供應商模式。作爲依賴方，主要考慮是否新增防腐層，防腐層的好處是依賴倒置，可以隨時替換下游，方便測試等，不過增加了模型轉換的成本。
jar包與package
在應用內部，一般會按照橫向的層級以及縱向的業務來劃分。
橫向的層級劃分按照領域驅動分層一般如下。
jar包一般可以按照上面的模式來劃分，不過也可以通過package的方式來組織，只是一種邏輯的代碼組織方式，另外有一些公共的功能模塊也可以抽在這一層級，例如異常、日誌、註解等。
然後是領域模塊下面按照各個聚合來劃分縱向的業務包package。
類
最後是類的填充與細化，可以是契約導向的編碼，由外而內，因爲外部的場景是確定，內部的模型可以通過場景來推到出來。
其他
上面基本列出了從領域模型到代碼劃分的大概過程，省略了很多細節，不過可以作爲實踐的一個指南，後面會結合一些具體的實例進行分析。