因為我司框架是基於DDD+外掛的模式,基於學習需要所以初步學習了DDD,並且請教了DDD的專家寬寬大佬.

DDD定義：領域模型應該捕抓“業務規則”或者“領域邏輯”（business rules/domain logic），而應用模型則捕抓“應用邏輯”（application logic）DDD把模型分成了四層：
* UI層，負責介面的展示。
* 應用層（），負責業務流層。
* 領域層（），負責領域邏輯。
* 基建層（），負責提供基建。

分類的依據：越往上，預期變動月頻繁；越往下，預期變動越小。UI只管展示，基建層（包括資料持久層）提供持續儲存、網路傳輸等等基礎建設，都沒有業務的參與。領域層與業務層區別?
1. 領域邏輯就是顯性的專業知識，是相對容易理解和學習的部分;
2. 領域邏輯是提純、通用的規則;

例子理解：領域建模好比如把業務流程拆分到對應業務參與人員上，財務、銷售、採購、決策、客服，領域劃分粒度隨著業務流程細化不斷變小，例如財務；拆分為出納、會計、審計如果覺得劃分到出納、會計、審計就能滿足業務了，就開始寫class了。這些還不是具體業務。。。具體業務是這樣的：使用者買保險！使用者買保險涉及到的流程會有多方參與，銷售開單、客服跟單、通知會計開具發票（如果需要）、出納收銀等等領域上各個領域自己負責的事情，可以稱為職責。

寬寬大佬簡單解釋：

有兩種處理方式：一種是“上帝視角”有兩種處理方式，一種是“上帝視角”即業務的所有細節，有一個上帝全部清楚，這樣的程式設計的結果就是一個核心的邏輯流程呼叫所有其他的功能
這麼做的前提是，能有這麼一個知曉一切的上帝。並且所有附屬功能都很簡單（比如就是讀取db，生成excel等）如果業務問題符合這個假設，這麼程式設計是最好的，因為業務邏輯非常清晰容易理解。就算你拆分成一塊一塊的，還是要一起用。耦合不因為你拆了就沒了。
但另外一個場景是，每個業務流程極端複雜。複雜到無法出現這麼一個上帝知曉一切細節。上帝只知道大概。這時每個業務單元都可以單獨實現成一個模組/服務。讓上帝來呼叫。這麼做的前提是，每個業務單元都相對獨立，並不會因為上帝的視角的改變而改變。（舉個例子，比如你要去政府申請開公司，政府說我的部門說3天稽核完，你想3個小時就完事，政府不會因為你的意願就給改成3小時。）其實這個就是我們日常工作的模擬，怎麼做整體是可控的。業務邏輯簡單就直接開搞。業務邏輯複雜就拆分成獨立的元件來協作。

然而，大多數人用不了DDD是因為業務邏輯沒有那麼複雜。Web就是這樣的，一個數據db讀出來，處理下輸出完事，而比如做一單保險的試算就麻煩大了；另外一方面是，業務邏輯拆解和效能需求是相反的拆得越細碎，越難做效能優化，這和政府效率不高很搭配）