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

標籤：style   blog   http   os   使用   strong   檔案   資料   2014   

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

 

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

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

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

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

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

     

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

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

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

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

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

      領域模型：專註於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係；

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

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

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

 

 

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

 

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