对我来说，这意味着深入组件、服务或模块的层次，它们各自都有一组特定的职责。值得强调的是，这不是理解底层实现细节，而是进行初步的分解。基于组件开发的维基百科页面1 有一个很好的总结，“组件”可能是像风险计算器、审计记录器、报表生成器、数据导入器等一样的东西。考虑一个组件最简单的方式就是，它是接口背后的一组相关行为，可以用一个或多个协作类实现（当然，假设是面向对象的语言）。好的组件和好的类有一些共性，应该高内聚、低耦合，有良好定义的公共接口、良好的封、装等。
1 http://en.wikipedia.org/wiki/Component-based_software_engineering
根据组件来考虑一个软件系统有很多好处，但本质上它让我们可以把软件看作少数高层次的抽象，而不是组成大多数企业系统中成百上千个类，来考虑和谈论。下面的照片展示了在我们举办的培训班上产生的一张典型的组件图。各组都要设计一个简单的金融风险系统 ，该系统需要拉取一些数据，执行一些计算，并生成一个Excel报表作为输出。
我们往往以组件为单位来思考
这张草图包含了你期望在一个导入数据、执行风险计算和生成报表的系统中看到的主要组件。这些组件为我们提供了一个区分我们系统内部行为的框架，这样在其中跟踪主要用例/用户故事就应该相对容易。这是软件开发过程中一个非常有用的起点，有助于建立团队能够为之努力的共同愿景。
但这同时也非常危险。没有技术选择（或选项），这张图看起来就像那种闭门造车的架构师的作品，对很多拥有技术背景的人来说，它显得非常“概念化”（或者“肤浅”，取决于你的观点）。