模块化倾向于代码的静态分割管理，而组件更倾向于服务运行的独立部署单元。组件在架构中常常以子系统或者分层出现，是许多事件处理器的可部署工作单元。另一种类型的组件(即服务)倾向于在它自己的地址空间中运行，并通过底层的网络协议（如TCP/IP）或更高层的格式（Restful或者消息队列）进行通信，从而在微服务等架构中形成独立可部署的单元。组件提供的模块比语言提供的最低级别的模块级别更高，一个服务可能包含足够的代码来保证组件的完整性，也可能足够简单。
| 划分 | 优点 | 缺点 |
|---|---|---|
领域划分: 通过工作流或领域将顶级组件分隔开 |
更接近于业务功能而不是实现细节的建模 更容易组建围绕领域的团队 更接近于模块单体和微服务架构风格 消息流匹配问题域 易于将数据和组件迁移到分布式架构中 |
定制化代码将会出现在多个地方 |
| 技术划分 技术划分的架构根据技术能力分离顶级组件。这些层可能受模型-视图-控制器划分或者其他技术划分的启发 |
清晰地分离定制代码 更接近分层架构模式 |
更高程度的耦合。对通用组件或本地组件的更改可能会影响所有组件 开发人员可能在本地层和通用层中重复引入领域概念 通常在数据级有更高的耦合，如果以后迁移到分布式系统中， 需要解决数据关系的问题如分布式事务 |
识别初始组件
基于顶级划分的类型，决定从哪些顶级组件开始。可以将领域映射到这些组件上;
将需求分配到组件
将需求或者用户故事与组件进行比对，以确定它们是否适合这些组件。
分析角色和职责
将用户故事分配给组件时，架构师还会查看需求阐明的角色和职责，以确保粒度匹配。架构师通过考虑应用程序必须支持的角色和行为，来调整组件和领域粒度。架构师面临的最大挑战之一是确定组件的正确粒度，这需要多次迭代才能实现
分析架构特征
在为组件分配需求，需要考虑到早期发现的架构特征，
若有收获，就点个赞吧
0 人点赞
