設計思想中有兩種極端：大而全、小而美。
一般我們常用的庫是小而美，用的框架是大而全。從Symfony實現Component式開發開始，框架的組件化逐漸成為趨勢。我們可以任意的組合各種Compoent來形成自己的PHP框架，比如B團隊出的Db及ORM引擎、B團隊出的緩存引擎、E團隊出的Route映射引擎、C團隊出的DI、D團隊出的MVC、X團隊的單元測試工具。Composer出現后，提供了高度便捷性，加速了這種趨勢。
Yii這個框架是典型的全棧式框架，常規應用開發所需功能幾乎都揉和到一個項目中。yii2到現在，它的核心實現還是以傳統Web應用場景為重心。但這只是他的形，他的核心思想里是組件化的，有Component這樣的完善機制，只是沒有拆開成各個子項目而已。
如何將Yii2這樣的項目拆成Component式的子項目呢，你可以自己想想！
代碼重用據說是OOP思想最想要解決的問題？如果我們寫出的每個功能，抽象的庫、具體的業務模塊，都可以實現最大化獨立和重用，似乎是很美好的一件事情，借助於開源的趨勢，若干年的積累后，只要像搭積木一樣組合一下，就可以完成滿足實際需求的應用系統。
請注意上文中的“搭積木”這個詞，搭積木源自於孩童時的游戲，不同的積木組合可以拼成各種房子、各種車等，但積木組合出來的都是人所處環境的實物，和應用系統這種存在於計算機世界的事物在目前的認知上是完全不同的體系，搭積木這個詞用在應用開發上，合適嗎？
通常我們的結論是這樣：代碼可以以庫的形式重用，重復的功能模塊式開發和引用，但不同的應用有不同的場景，還是需要以比較“巧妙”的方式去定制的，比如“鈎子”、“行為”、“事件”、“插件”等。
話再說回來，組件化可以到什么程度呢？
市面上成功的CMS等系統都通過“插件”或“擴展”，配合“應用市場”建立了比較強大的開發者生態圈，通過“巧妙”的機制實現具體場景的定制化，滿足用戶的需求。
舉個簡單的例子來說，TP的Model是這樣的：
在具體的Model里如UserModel，覆蓋
// 刪除數據前的回調方法
protected function _before_delete($options) {}
// 刪除成功后的回調方法
protected function _after_delete($data,$options) {}
這兩個方法以實現數據刪除前和刪除后觸發的關聯操作，但Yii中，只要繼承Component基類實現的類，都可以使用事件和行為來擴展原來的邏輯，而且可從外部來定義，非常靈活。
yii中的用法大致為：
$model = new User;
$model->on(‘before_delete’, $callabe, $data);
TP的控制器中也有鈎子，應該也算是一種實現方式吧。
庫Component化、業務功能以模塊化的方式實現，就可以實現擴展和定制的無限可能性。