10、软件架构组件识别与设计指南

软件架构组件识别与设计指南

1. 架构分区概述

在新项目中，架构师首要任务之一是识别组件，而在此之前，需掌握如何对架构进行分区。软件架构第一定律表明，软件中的一切都是权衡的结果，包括架构师创建组件的方式。架构分区有多种常见风格，各有不同的权衡。

常见的两种顶级架构分区类型为分层架构和模块化架构：
- 分层架构 ：将系统功能按技术能力划分，如表示层、业务规则层、服务层、持久化层等。这种架构易于开发者查找相关代码，且与MVC设计模式匹配，常为许多组织的默认架构。例如，持久化代码集中在一层，方便开发者定位。
- 模块化架构 ：受领域驱动设计（DDD）启发，围绕领域或工作流划分架构，而非技术能力。微服务架构风格就基于此理念。在模块化单体架构中，架构师围绕领域或工作流进行分区。

2. 技术分区与领域分区对比

2.1 技术分区

技术分区按技术能力组织系统组件，其优点和缺点如下：
| 优点 | 缺点 |
| — | — |
| - 明确分离定制代码
- 更符合分层架构模式 | - 全局耦合度高，对公共或本地组件的更改可能影响其他组件
- 开发者可能需在公共和本地层重复领域概念
- 数据层耦合通常较高，迁移到分布式系统时难以理清数据关系 |

例如，在分层架构中，处理CatalogCheckout业务流程的代码会分散在各个层，导致领域概念在技术层中分散。

2.2 领域分区

领域分区按工作流和/或领域分离顶级组件，其优点和缺点如下： <