10、软件架构组件识别与设计全解析

软件架构组件识别与设计全解析

1. 架构分区的重要性与类型

在新的软件项目中，架构师首要任务之一是识别组件，而在此之前，必须先了解如何对架构进行分区。软件架构第一定律表明，软件中的一切都是权衡的结果，架构师创建组件的方式也不例外。由于组件是一种通用的容器机制，架构师可以采用各种分区方式，常见的有以下两种：
- 分层架构 ：这是一种基于技术能力的顶层分区方式，将系统功能划分为不同的技术层，如表示层、业务规则层、服务层和持久化层等。这种方式便于开发人员查找特定类型的代码，例如所有持久化代码都集中在持久化层。同时，它与MVC设计模式相匹配，易于理解，因此常成为许多组织的默认架构。不过，分层架构也存在一些问题，例如当处理跨越多个技术层的业务流程时，代码会分散在各个层中，导致业务领域被“涂抹”在技术层上。
- 领域分区架构 ：受领域驱动设计（DDD）的启发，架构师根据独立且解耦的领域或工作流来划分架构。在模块化单体架构中，架构围绕领域或工作流进行分区，而不是基于技术能力。每个顶级组件可能包含子组件和层，但顶级分区主要关注领域，能更好地反映项目中常见的变更类型。

2. 康威定律及其影响

康威定律指出，设计系统的组织最终会产生与组织沟通结构相似的设计。在采用分层架构的组织中，根据技术能力划分团队是常见的做法，例如后端开发人员、数据库管理员和表示层团队分别在不同的部门。这种组织方式虽然在一定程度上有其合理性，但也会因人为分离共同关注点而阻碍团队协作。与之相关的是ThoughtWorks的Jonny Leroy提出的反康威策略，该策略建议团队和组织结构共同演进，以推动所需的架构。