十一、EnterpriseFrameWork架構的分層與系統業務的結合

       上章詳細講了EnterpriseFrameWork架構中的每個分層，這都是從技術層面來說明，也就是我們知道怎麼來建一個控制器或一個業務對象，但開發過程中應該建一個什麼樣的控制器或業務對象了？本章的主要内容是說明根據系統業務、客戶需求如何來設計合理的控制器和業務對象。

 檔案要點：

1.粗略介紹系統分析設計過程

2.架構分層結構怎麼結合業務

      大概介紹一下我對開發一個系統的分析設計過程吧，決定開發某個系統後，肯定是先了解系統相關業務内容，根據自己的見識這個應該屬于哪一類的系統，是類似進銷、還是收費系統或其他，也在網上也找找有沒有類似業務的系統；這些在開發一個系統前都是很值得參考與分析的資料；這樣你心裡也有了個底，自己團隊能不能做出來，要花多長時間、多大資源才能完成；心裡有底後就可以三闆斧完成整個系統分析設計過程，

      第一，根據客戶需求，結合業務場景畫出一些業務活動圖、用例、實體等

      第二，接着根據經驗或了解了設計出界面原型和資料庫結構

      第三，然後針對關鍵性系統問題進行領域分析得到領域對象模型

這樣系統的分析設計已初步完成，然後就是把設計轉化為代碼，以後随着對業務的深入了解而進行不然疊代提升；而且個人覺得用例圖與領域模型可以很好的幫助自己在業務方面的了解；

      再看下面幾個問題在修改代碼的時候經常碰到，

      1）修改一處關聯性功能問題，往往一串代碼檔案，因為把實作代碼分散在多個代碼檔案中而沒有放在一個檔案中；

      2）修改一個關鍵性系統問題，往往會修改多個子產品的代碼才能徹底解決，因為你并沒有把解決這個問題的代碼封裝成業務對象；

解決這兩個問題就是我們的代碼的分布一定要與實際業務要對應；讓我們可以快速找到需要修改的代碼并花最小代價完成修改；

      用例：是描叙在邏輯上相對完整的功能流程；

      領域模型：專注于分析問題領域本身，發掘重要的業務領域概念，并建立業務領域概念之間的關系；

       我們把用例和領域模型換成縱向和橫向兩個角度來看上面兩個問題，一個關聯性很強的功能問題都對應着某個用例，而關鍵性系統問題都應該進行領域分析得出領域對象模型；是以把修改内容控制在一個用例中或一個領域對象模型中，就很容易控制和實行；與功能問題密切相關的不就是界面與Controller控制器，而與系統級問題相關的不就是ObjectModel業務對象；

       Controller與ObjectModel沒有包含或被包含的關系，兩者完全是平級的；一個Controller可以調用多個Object，而一個Object同樣可能被多個Controller調用；為什麼這麼對應，也是友善更容易的了解代碼，保持代碼閱讀的連貫性；如果在代碼設計過程中沒有一個指導性思想，是很容易混淆代碼檔案的，如：糾結的是一個類或方法不知道放在哪更合适，就跟給多個控件或變量起名一樣困難；

       由此在項目中使用架構的過程中，反過來再看之前的系統業務分析與設計得出：架構中的Controller對應業務中的用例，ObjectModel對應業務中的領域對象模型；見下圖

        由于本章的内容沒有什麼具體的代碼和執行個體，都是一些形而上的見解，是以難免會有個人的局限性，但是說的都是在實際項目中的經驗和領悟；這些東西個人覺得講解一些個人經曆來進行引導性思考，比擺出一套完整的理論應該更合适；比如系統分析師或系統設計師，不可能通過學習兩本大牛的書籍就能成為的，而是不斷在項目中通過你的經驗累積磨練而成的，一個系統設計師把自己的方法與套路交給你，而你也不是學會了就能夠成為一個系統設計師的；既然這樣那還不如講講個人經曆，講講走到每個階段的心情與感悟，這樣可能會更容易産生共鳴；