以后簡稱作者為巨牛。^_&

第四章講解的重點就是分離.領域的分離.

說實在的,讀之前覺得,自己的設計模式用的也比較熟練了,OOP的設計也做過很多個了,分離什么都是小兒科.讀完之后才發現,以前的設計都是智能UI設計.一種無法復用,無法正確擴展的設計.

首先,書中解說了下為什么要分離,核心思想就是:解耦.

然后，明確指出，領域要和什么技術實現啊，用什么緩存之類的統統隔離。越簡單越明了就越好.

然后在最后提出了一種很不好的設計:智能UI設計

來說下巨牛對智能UI設計的解釋:

把所有的業務邏輯交給用戶界面處理。把整個應用程序分割成小的功能函數(也就是小的業務模塊,如何分割的話就要看模塊之間的關聯度了)，并且把他們作為相互獨立的用戶界面來實現，同時把業務規則嵌入到這些界面中（我覺得如果在界面中涉及到過多的業務邏輯,就算把業務規則放在service層中實現，也還是相當于把業務規則嵌入到界面中了）.用一個關系數據庫作為數據的共享倉儲.使用最自動化的UI結構,以及可利用的可視化編程工具.

然后列舉了智能UI設計的優勢和缺點.(呵呵,我還是比較認同的,客戶的要求是最重要的,特別是針對的是項目,如果是產品的話,就不能這么做了).先說優點:

1. 對于簡單的應用,生產力較高(呵呵,還是較高而已),開發時間較短.

2. 缺少經驗的開發人員可以進過較短的培訓直接上手.

3. 甚至在進行需求分析時所留下的缺陷,可以通過把原型提供給用戶來克服,并快速的在軟件中做出修改來滿足用戶的要求.(這個一定要是簡單應用啊).

4. 應用可以相互分離,所以能夠精確的計劃遞交小模塊的進度表.對系統的簡單擴展可能會很容易.

5. 關系數據庫工作可靠,并且提供數據級上的集成.

6. 第4代語言（JAVA什么的）功能能很好的滿足開發需要。

7. 檔這個應用程序被遞交后，維護程序員能夠很快的重新開發他們（開發人員）沒有解決的部分，因為改變所帶來的影響只局限在每個特定的UI中。

好了，列了很多優點后，現在開始說缺點了：

1. 應用的集成比較困難，除非利用數據庫。關于這點說下我的想法：比如開始做了個人事考勤的系統，里面有組織結構模塊，人員管理模塊，考勤模塊。現在呢，客戶又想要個考試管理，那么我的人員管理模塊和組織結構模塊在當時沒有考慮支持其他系統的功能，最簡單的做法就是把數據庫放到一起去，后加的功能直接去訪問數據庫。再呢，就是改原來的。反正就是不能重用。

2. 這里不會考慮重用以及業務問題的抽象。業務規則必須在每個使用它（上面提到的人員管理模塊）的操作中復制。

3. 缺少抽象的提煉而限制了重構的選擇（比如考試系統中有學員和教師等各種角色），所以快速原型和迭代收到了天然的限制。快速原型的概念：http://baike.baidu.com/view/408667.htm

4. 復雜性很快會讓你迷失（這個真的只能意會了），所以增長路線只能嚴格順著原有的應用上添加簡單應用而已。想要獲得具有豐富行為的應用并不容易。

總結就是：如果一個基于產品的簡單項目，客戶拿去忽悠賺錢的，用一次就丟掉的項目，用智能UI設計的方法是基本上沒什么問題的。但是，采用這種模式的一個后果就是你不能把它移植到另外一種設計方法中，除非替換整個應用程序。

好了，第四章看完了。有些啟發，有些疑問。需要在后面的章節中尋找。

Domain-driven?design

轉載于:https://www.cnblogs.com/marxTen/articles/3120243.html

總結

以上是生活随笔為你收集整理的领域驱动第四章-读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。