上章詳細講了EnterpriseFrameWork框架中的每個分層，這都是從技術層面來說明，也就是我們知道怎么來建一個控制器或一個業務對象，但開發過程中應該建一個什么樣的控制器或業務對象了？本章的主要內容是說明根據系統業務、客戶需求如何來設計合理的控制器和業務對象。
文件要點：
1.粗略介紹系統分析設計過程
2.框架分層結構怎么結合業務
大概介紹一下我對開發一個系統的分析設計過程吧，決定開發某個系統后，肯定是先了解系統相關業務內容，根據自己的見識這個應該屬於哪一類的系統，是類似進銷、還是收費系統或其他，也在網上也找找有沒有類似業務的系統；這些在開發一個系統前都是很值得參考與分析的資料；這樣你心里也有了個底，自己團隊能不能做出來，要花多長時間、多大資源才能完成；心里有底后就可以三板斧完成整個系統分析設計過程，
第一，根據客戶需求，結合業務場景畫出一些業務活動圖、用例、實體等
第二，接着根據經驗或理解了設計出界面原型和數據庫結構
第三，然后針對關鍵性系統問題進行領域分析得到領域對象模型
這樣系統的分析設計已初步完成，然后就是把設計轉化為代碼，以后隨着對業務的深入理解而進行不然迭代提升；而且個人覺得用例圖與領域模型可以很好的幫助自己在業務方面的理解；
再看下面幾個問題在修改代碼的時候經常碰到，
1）修改一處聯動性功能問題，往往一串代碼文件，因為把實現代碼分散在多個代碼文件中而沒有放在一個文件中；
2）修改一個關鍵性系統問題，往往會修改多個模塊的代碼才能徹底解決，因為你並沒有把解決這個問題的代碼封裝成業務對象；
解決這兩個問題就是我們的代碼的分布一定要與實際業務要對應；讓我們可以快速找到需要修改的代碼並花最小代價完成修改；
用例：是描敘在邏輯上相對完整的功能流程；
領域模型：專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關系；
我們把用例和領域模型換成縱向和橫向兩個角度來看上面兩個問題，一個聯動性很強的功能問題都對應着某個用例，而關鍵性系統問題都應該進行領域分析得出領域對象模型；所以把修改內容控制在一個用例中或一個領域對象模型中，就很容易控制和實行；與功能問題密切相關的不就是界面與Controller控制器，而與系統級問題相關的不就是ObjectModel業務對象；
Controller與ObjectModel沒有包含或被包含的關系，兩者完全是平級的；一個Controller可以調用多個Object，而一個Object同樣可能被多個Controller調用；為什么這么對應，也是方便更容易的理解代碼，保持代碼閱讀的連貫性；如果在代碼設計過程中沒有一個指導性思想，是很容易混淆代碼文件的，如：糾結的是一個類或方法不知道放在哪更合適，就跟給多個控件或變量起名一樣困難；
由此在項目中使用框架的過程中，反過來再看之前的系統業務分析與設計得出：框架中的Controller對應業務中的用例，ObjectModel對應業務中的領域對象模型；見下圖
由於本章的內容沒有什么具體的代碼和實例，都是一些形而上的見解，所以難免會有個人的局限性，但是說的都是在實際項目中的經驗和領悟；這些東西個人覺得講解一些個人經歷來進行引導性思考，比擺出一套完整的理論應該更合適；比如系統分析師或系統設計師，不可能通過學習兩本大牛的書籍就能成為的，而是不斷在項目中通過你的經驗累積磨練而成的，一個系統設計師把自己的方法與套路交給你，而你也不是學會了就能夠成為一個系統設計師的；既然這樣那還不如講講個人經歷，講講走到每個階段的心情與感悟，這樣可能會更容易產生共鳴；