1.1 為什么DDD難落地？
洋蔥架構圖：
DDD能解決什么問題？
其實DDD的核心是：提升業(yè)務的聚合性、提升業(yè)務的拓展性。
DDD的錯誤認知？
很多人首先想找一個DDD的框架來學習？
學習DDD層次和DDD的領域概念？
DDD不適合小項目，只適合產品或大項目？
大部分人都容易陷入到四層架構和各種DDD對象的概念上出來，以為這些概念用好了就可以了，如果只是研究這些概念，那就完全錯了，因為這些框架與概念都只是其表象。
DDD是怎么來的？
我沒有考證具體DDD的由來，但是我一直給很多人說，DDD其實是面向對象（OOP）的一種落地方式。
DDD的建議學習路線？
編輯基礎->面向對象->設計模式->領域驅動
DDD初學者的兩大門檻？
面向數據驅動轉化為面向對象驅動，業(yè)務邏輯的控制由數據庫的控制轉交給對象控制。
理解面向對象的概念與本質。
開閉原則的理解？
在面向對象編程領域中，開閉原則?(The Open/Closed Principle, OCP) 規(guī)定“軟件中的對象（類，模塊，函數等等）應該對于擴展是開放的，但是對于修改是封閉的”[1]，這意味著一個實體是允許在不改變它的源代碼的前提下變更它的行為。該特性在產品化的環(huán)境中是特別有價值的，在這種環(huán)境中，改變源代碼需要代碼審查，單元測試以及諸如此類的用以確保產品使用品質的過程。遵循這種原則的代碼在擴展時并不發(fā)生改變，因此無需上述的過程。
代碼越多越容易出現錯誤，所以我們要拆分，要聚合。或者說就是提升可維護性、可復用性。
拆分是指，把大段代碼拆分成小段代碼。其實就是層次劃分與對象定義的過程。
你怎么拆分？依據（DDD）
為什么這樣拆分？方法（業(yè)務聚合）
聚合是指，把相同智能的代碼可以不斷復用。
軟件世界的烏托邦：
不修改已有代碼通過增加新的代碼即可實現對功能的調整
代碼可被高效的復用
增加新的功能只直接測試當前新的功能質量，且不會對之前的功能產生影響。
非常容易的驗證代碼質量（單元測試的覆蓋度高）
代碼易讀性強，層次清晰，規(guī)范統(tǒng)一
