组件提供了一种将功能划分的方式，可以分开安装和部署。
组件设计的常用原则
在设计组件的时候，可以参考下面的原则：
- 对于组件中的类，应该遵守S.O.L.I.D的类设计原则。这方面大家可以参考：面向对象设计的SOLID原则。简单的说，S.O.L.I.D原则就是：
- Single responsibility principal：单一职责原则，一个类应该只有一个职责。
- Open/Closed principal：开放封闭原则，类应该支持扩展，而不是去修改它。
- Liskov substitution principal：里氏替换原则，子类应该可以被基类替换。
- Interface segregation principal：接口分离原则，不同的客户端，不同的需求，应该暴露不同的接口。
- Dependency inversion principal：依赖倒置原则，对类的依赖应该被抽象代替，抽象不应该依赖细节，细节应该依赖于抽象。
- 设计的组件应该是高内聚的。不要添加无关的的功能，或者是混合其他的功能，使得类的负担过重。例如：在业务组件中要避免将数据访问和业务逻辑混合在一起。只有当功能内聚，你创建的程序集就可以包含多个组件，就可以将组件安装在适当的应用层中，甚至是部署在独立的物理层。
- 一个组件不应该依赖于其他组件的内部实现。每个组件和对象应该调用另外一个对象和组件的方法，方法包括如何处理请求，如果需要的话，应该会路由到适当的子组件或者是其他组件。
- 理解组件之间是如何通信的。你一定要考虑通信是否跨越物理边界，还是跨越进程边界，还是所有的组件都运行在同一个进程。
- 保持跨层关注的代码从应用逻辑中抽象出来。跨曾关注的代码，例如：安全，通信，操作管理，日志和性能仪表盘。将这些代码混合在组件中，会导致系统难以维护和扩展。
- 应用组件为基础的架构风格的关键原则。包括可重用性，可替代性，扩展性，封装性，独立性，不和特定上下文相关。
分层组件分布
应用的每一层都有很多实现本层功能的组件。这些组件应该是内聚的，松散耦合的，简化重用性和维护性。下图显示了每一层的组件类型。
表现层组件
表现层组件实现的功能需要允许用户和应用进行交互。在设计的时候可以参考下面的原则：
-
用户界面组件。应用的用户界面被封装在用户界面组件中。他们是应用的可视化元素，给用户显示信息，并且接收用户的输入。
-
表现层逻辑组件。表现逻辑是一些定义逻辑行为的代码，以及独立于用户界面的代码。他们通常负责组织从业务逻辑层来的数据，将他们组织为用户界面可以消费的格式，方便数据的显示。表现层组件又可以分为两个部分：
-
Presenter，Controller，Presenter Model，ViewModel组件。这些组件封装表现层的表现逻辑。最大化支持重用和可测试性，这些组件和特定的用户界面、元素、控件没有关系。
-
表现层的实体组件。这些组件封装了表现层的数据，使得数据很容易被用户界面消费。例如：数据类型的转换。在某些情况，可能是从业务逻辑层来的实体直接被消费，也可能会转换成用户界面可以消费的实体。
-
服务层组件
你的应用可能暴露出服务层，供客户端或者是其他系统交互。服务层提供客户端和其他系统一种访问业务逻辑层的方式，通过消息使用系统的功能，通常包括下面的内容：
-
服务接口。服务层暴露服务接口，你可以将服务接口看做是暴露应用业务逻辑层的外观模式。
-
消息类型。在和服务层进行数据交互的时候，数据结构背包装在消息中。
业务层组件
业务逻辑层组件实现了系统的核心功能，封装了业务逻辑。通常包括下面类型的组件：
-
应用外观。这个可选的组件提供一个简化了的业务逻辑组件，通常将多个业务操作组合成一个，使得业务逻辑更容易使用。减少依赖性，因为外部调用者不知道业务组件的细节，及他们之间的关系。
-
业务逻辑组件。通常包括:
-
业务流程组件。
-
业务实体组件。
-
数据访问层组件
数据访问层组件提供了数据访问，向其他网络系统暴露数据，通常包括下面的部分：
-
数据访问组件。组件抽象了数据访问的逻辑。工具和帮助组件通常封装在一个独立的框架中，方便在其他应用中使用。
-
服务代理。当业务逻辑一定要使用外部服务提供的数据，你可能需要一个管理和外部通信的代理。
跨层关注的组件
很多功能需要在很多层实现。例如：
-
实现安全的组件。包括用户验证，授权，验证。
-
实现操作管理的组件。异常处理策略，日志，性能计数器，配置，跟踪。
-
实现通信的组件。
相关的设计模式
| 分类 | 相关模式 |
| Business Component |
|
| Business Entity |
|
| Presentation Entity |
|
| Presentation Logic |
|
| Service Interface |
|
| Workflow |
|