對我來說，這意味著深入組件、服務或模塊的層次，它們各自都有一組特定的職責。值得強調的是，這不是理解底層實現細節，而是進行初步的分解。基於組件開發的維基百科頁面1 有一個很好的總結，「組件」可能是像風險計算器、審計記錄器、報表生成器、數據導入器等一樣的東西。考慮一個組件最簡單的方式就是，它是接口背後的一組相關行為，可以用一個或多個協作類實現（當然，假設是面向對象的語言）。好的組件和好的類有一些共性，應該高內聚、低耦合，有良好定義的公共接口、良好的封、裝等。
1 http://en.wikipedia.org/wiki/Component-based_software_engineering
根據組件來考慮一個軟件系統有很多好處，但本質上它讓我們可以把軟件看作少數高層次的抽像，而不是組成大多數企業系統中成百上千個類，來考慮和談論。下面的照片展示了在我們舉辦的培訓班上產生的一張典型的組件圖。各組都要設計一個簡單的金融風險系統 ，該系統需要拉取一些數據，執行一些計算，並生成一個Excel報表作為輸出。
我們往往以組件為單位來思考
這張草圖包含了你期望在一個導入數據、執行風險計算和生成報表的系統中看到的主要組件。這些組件為我們提供了一個區分我們系統內部行為的框架，這樣在其中跟蹤主要用例/用戶故事就應該相對容易。這是軟件開發過程中一個非常有用的起點，有助於建立團隊能夠為之努力的共同願景。
但這同時也非常危險。沒有技術選擇（或選項），這張圖看起來就像那種閉門造車的架構師的作品，對很多擁有技術背景的人來說，它顯得非常「概念化」（或者「膚淺」，取決於你的觀點）。