在 “軟件設計要素初探” 一文，嘗試從軟件設計的整體角度，綜合討論了軟件設計的各種要素。本文討論用於系統划分的組件化思想。
概述###
將整個系統划分為若干正交的緊密關聯的子系統，以及高內聚低耦合的小而美的模塊與微服務，理清職責、交互與邊界。划分的基本原則是“識別、分離和組合關注點”。每個子系統必定有其核心關注點和基礎關注點，而基礎關注點中交疊的部分，即是子系統交互定義的基礎。
組件化###
組件化是可靈活組合和可定制的前提，是構建大型軟件應用的核心思想。組件化的基本技巧是“識別和分離關注點”。心里沒有“關注點”概念的開發者，寫代碼時比較隨意，在實現功能時無意識將多個關注點摻雜在一起，當關注點發生變化需要重組時，“for-ififelseif-for-ifelseif-switch”的噩夢開始誕生了。而善於“識別和分離關注點”的開發者則會想辦法把這些關注點解耦開，實現成簡潔可組合的短小函數、方法和類，並置於該歸屬的地方。組件化的另一個基本技巧是“面向接口編程”：先創建所需要的組件接口，然后創建基於組件接口的應用骨架，最后根據需求和場景創建和注入具體實現。盡管有時這種做法顯得“有點過度設計”，卻更有易於理解系統流程。
組件化可以從不同粒度上進行。
(1) 單個應用。單個應用內的組件化，主要是將單一關注點的邏輯功能組件化，能夠靈活組合和配置；亦可將緊密關聯的小組件串聯成更大粒度的更實用的組件。比如一個訂單導出應用，其流程是：訂單搜索 -> 訂單詳情獲取與拼接 -> 訂單過濾 -> 詳情數據格式化 -> 結合報表模板生成報表 -> 上傳報表文件。將每個步驟定義成一個組件接口(訂單搜索組件接口、獲取詳情組件接口、訂單過濾組件接口、訂單詳情格式化組件接口、報表生成器組件接口、上傳文件組件接口)，再定義一個全局控制器，將組件接口串聯成導出流程，而具體的導出實現只要傳入指定組件接口的具體實現即可。訂單搜索可以從DB查詢，亦可以從 ES 查詢；訂單詳情可以從API接口獲取，亦可以從Hbase獲取。為保證大批量數據導出的性能，減少業務數據庫和業務接口的壓力，推薦使用 ES + Hbase 組合。
組件化之后，亦容易實現可定制化。 比如有的導出只需要導出 ES 表里的記錄；有的導出只需要導出 Hbase 表里的記錄；而略微復雜的導出則需要從 ES 和 Hbase 同時獲取數據。這就需要根據參數配置對組件進行靈活組合。
(2) 多個應用構成了更大粒度的領域服務組件。一些互聯網企業開始推行“服務化架構”，每個服務化工程就是一個組件。比如訂單管理組件可由訂單搜索/訂單詳情/數據同步/發貨組件/訂單導出組件等組成；交易服務組件可由下單服務組件、訂單管理組件、逆向交易組件以及輔助組件(比如交易消息推送組件、核銷組件)組成。
(3) 多個特定領域服務組件構成更大粒度的行業服務。比如交易、營銷、商品、會員等服務組件可構成電商SAAS的雲服務能力。比如擁有完整微商城能力並致力於移動零售領域的有贊雲。
組件協作###
嘗試從更大范圍的系統領域來思考和設計組件以及組件之間的協作結構。比如訂單導出需要從ES和Hbase搜索訂單和獲取訂單詳情，而ES和Hbase的訂單數據則依賴於從消息、DB或API接口進行數據獲取和存儲的數據同步組件。因此，大數據存儲設計、數據同步對於訂單導出的整體設計尤為重要。
訂單導出的比較棘手的一個問題是，數據源通常來自於多個分散的業務表，這樣導致同步設計重而且不靈活。如果制定一種標准，需要導出的字段必須落在下單表的字段或擴展字段里，那么就可以有效地解決數據源分散的問題，而集中精力於解決導出可擴展可配置的問題。此時，下單、同步、導出成為密切關聯的一體化設計。當從單系統上難以尋求解決方案時，不妨從更大系統范圍去發現。
創建組件，定制組件，設計和復用組件協作結構，組合出更大結構的組件，從而能夠創建更大型更綜合的大規模軟件系統。
設計優良的系統，通常有一個清晰的組件化的骨架。組件化的骨架，就是可定制和可擴展的基礎支撐。