Posted on 2010-06-20 23:37
切爾斯基 閱讀(2239)
評論(2) 編輯 收藏
同一個Feature的代碼要放在一起(IDE里單獨的一個工程, 或者工程里單獨的一個文件夾), 這些代碼要么全有要么全無的, 它們合作完成一個Feature, 如果用戶不再需要這個Feature了, 可以把它們整個的痛快的刪掉, 不會留下誰也用不到的代碼成為系統的垃圾. 如果想看一個Feature是如何實現的, 那所有相關代碼都在一起, 不需要在龐大的代碼庫中跳來跳去.
那么理想的情況就是: 你看看源代碼樹里所有工程文件的名字, 或者文件夾的名字, 就知道系統提供了哪些功能, 它可以跟你的需求描述對應起來, 無論用User Story還是Use Case, 都可以用它們的名字作為工程名或者文件夾的名字, 方便維護
流行的MVC框架缺省的物理文件組織并不是這樣的, Controller, Model, View分別在不同的文件夾里面. ASP.Net MVC提供了VirtualPathProvider以及ViewEngine, 可以讓我們把一個Feature的Controller/Model/View統統打包到一個project或者文件夾而運行時依然能夠找到對應的action和view, 這是我們正在利用的特性
這種代碼組織方式對架構的影響是什么?
這基本會導致基于插件/擴展點的體系結構. 放到更大尺度上, 就是SOA. SOA才是王道. 這個詞太大了, 還是先聚焦到一個進程的應用....
1. UI如何聚合? 最終用戶看到的UI, 是一個聚合的結果, 可能來自系統的不同部分. 解決這個問題的擴展點技術有客戶端的Ajax, 或者服務端的RenderAction. (問題: Css應該如何處理? 不同部分的顯示順序, 布局如何確定?)
2. Feature如何溝通? Feature之間不可能一點依賴沒有, 比如可能會用到相同的數據, 相同的業務邏輯. 解決這個問題的方法有Bounded Context, Context Mapping, DCI...都是一回事
3. 數據庫如何劃分? 不同的Feature使用自己的獨立定義的數據表, 做映射和同步, 也是同樣的方案
4. 如何把這些Feature組裝在一起? Java平臺有OSGi, .Net目前沒有看到跟OSGi類似的方案. 基本是注冊或動態發現的路子, 遵循開閉原則...