知識體系驅動設計

　　如何指導你的設計，在DDD看來是領域知識驅動，但是比起DDD更提升一層的理念，應該是知識體驅動設計。

• 第一件事，對領域進行充分的理解，其實統一語言就是為了幫助軟件開發軟件去理解知識的，本質上是一種軟件開發者獲取知識的交流手段
• 第二件事，是對問題本質的思考，對問題本質的思考，意味你需要看透你所面臨的軟件開發是什么問題。
  • 如果你只是一個外包仔，那么你不需要思考太多不能歸你掌控的事情，能if就if；
  • 問題是否具備邏輯特性，具有邏輯性，可以推理的特點，是掌控萬變不離其宗的核心，也是本質復雜度的核心；
  • 問題本身具有多少長期內不容易變特性，多少抽象特性，是否有去建立模型的價值；
• 第三件事，是最痛苦的階段，根據你對問題的思考，建立一個知識體系，用該體系去解析問題，這一步也稱之為建模，但比起軟件建模，更多的是思維上的建模，在內心/大腦成立一套模型出來；
第四件事，代碼實現，其實內存和代碼都是丑陋的，他們都受技術影響，因此DDD的domain其實也不純粹，只要知識體系是完備的，這個時候，各種具體的開發工作，都應該圍繞著這個知識體系去進行，考慮下面幾點可以讓你更加清晰明白什么是知識體系驅動設計。
• 如何用GO和JS去實現DDD呢？
• 能不能理解線程和過程的區別呢？他們在知識體系中起到什么作用呢？
• 第四件事，通常第三件事可能伴隨模型突破，但是軟件大部分是長期迭代才能沉淀出越加穩定和完善的知識體系，所以問題生命周期越長，就需要繼續演進知識體系。

知識本質突破模型

　　模型突破是很重要的事情，它體現了知識的進一步提煉。知識的突破，一個簡單的方式就是在眾多概念中，挖掘中對解決問題內聚的概念，并顯式它，封裝它。

　　舉個例子1：一個流程的某一部分的協調進行需要預約，如果這個預約和完成這個預約對流程有影響，那么可以把預約這個領域概念刻畫出來。并且單獨狀態化（也就是不需要其他因子來判斷當前流程是否正在預約或者是否完成預約，而是全部依賴這個預約的狀態）。然后圍繞這個預約實體，做相關的業務操作；

　　舉個例子2：命令模式的引入，這里是把命令顯式化；