Question

在展示了高层次技术决策的容器图之后，我将开始放大，进一步分解每一个容器。如何分解你的系统取决于你自己，但我倾向于鉴别主要的逻辑组件及其交互。这关系到将一个软件系统实现的功能划分为若干不同的组件、服务、子系统、层、工作流等。如果你遵循一种“纯面向对象”或领域驱动设计的方法，那么这对你可能管用，也可能不管用。

意图

组件图可以帮助你回答下面的问题。

1.系统由哪些组件/服务组成？

2.在高层次上，系统如何工作是否清晰？

3.所有组件/服务都有一个家吗（即驻留在一个容器中）？

结构

每当人们被要求绘制“架构图”时，最后通常会绘制一张展示组成软件系统的逻辑组件的图。除了我们一次只想看一个容器中驻留的组件，这基本上就是图的作用。如果你在设计一个金融风险系统的解决方案，这里有一些组件图的例子。

金融风险系统（见附录）的组件图示例

我画的组件图通常只展示驻留在单个容器内的组件。这并不是一条规定，对于小型的软件系统而言，通常也可以用一张图展示所有容器中的全部组件。如果这张图开始变杂乱，说不定就是时候拆分它了。

组件

设计一个金融系统风险的解决方案可能会包括如下组件：

贸易数据系统导入器；

参考数据系统导入器；

风险计算器；

认证服务；

系统驱动者/协调者；

审计组件；

通知组件（如电子邮件）；

监测服务；

等等。

这些组件是系统的粗粒度结构单元，你应该能理解如何通过一个或多个组件实现一个用例/用户故事/特性。如果能做到这一点，那么你很有可能已经掌控了每件事。举个例子，如果你有一个访问审计系统的需求，但没有审计组件或职责，那么也许你已经漏掉了什么。

对于图中绘制的每一个组件，你都可以指定：

名称：组件的名称（如“风险计算器”、“审计组件”等）；

技术：对组件的技术选择（如：普通的[Java|C#|Ruby|其他]对象、企业JavaBean、Windows通信基础服务等）；

职责：对组件职责的非常高层次的声明（如：要么是重要的操作名称，要么是描述职责的简短句子）。

交互

为其他类型的图重申相同的建议，对标注组件间的交互行为非常有用，而不仅仅是由一堆框和意义不明的连接线组成的图。下面是一些有用的信息：

交互的目的（如：“使用”、“存留贸易数据”等）；

通信方式（如：同步、异步、批量、两阶段提交等）。

动机

把你的软件系统分解成多个组件，这在软件设计中比类和代码的抽象层次略高。审计组件可能是用连接了日志框架（比如，log4j、log4net等）的某个类实现，但把它当作一个单独的组件来对待，也可以让你看到它是什么，它是你的架构中的结构单元。在这一层次工作，对于了解你的系统内部结构是一个很好的方式，哪里可以复用、哪里有组件之间的依赖、哪里有组件和容器间的依赖，等等。把整个问题分解为若干个独立的部分，也为你开始做一些高层次预估提供了基础，如果你曾经被要求对一个新项目做大概的预估，这就非常棒。

组件图展示了驻留在每个容器中的逻辑组件。这很有用，因为：

展示了在高层次上将你的软件系统分解为职责不同的组件；

展示了组件之间的关系和依赖；

为软件开发的高层次预估和如何分解交付提供了一个框架。

在这个抽象层次上设计一个软件系统，完全可以在数小时或数天内完成，而无需几周或几个月。它也为你做好了准备，可以在类和接口的层次上设计/编码而无需担心整体高层次结构。

受众

软件开发团队中的技术人员。

示例

如容器图所示，“技术部落”包含一个从Twitter、GitHub和博客拉取内容的独立进程。就组件而言，下图展示了内容更新器高层次的内部结构。

“技术部落”—组件—内容更新器
独立Java进程

除了一些核心组件（见下），内容更新器由四个组件组成：一个计划内容更新器，一个Twitter连接器，一个GitHub连接器和一个新闻订阅连接器。这张图展示了内容更新器如何拆分为组件，这些组件是什么，它们的职责以及技术/实现细节。这里是核心组件。