软件架构中的组件方法

组件化架构：从单体到可扩展系统

组件化架构将目录视为图表中的构建模块，依赖关系则像连接线。每个组件就是一个代码目录，编译成库。依赖由构建工具管理，例如 crm/core 会引入 crm/api 和 payments/api，以集成支付网关。

这种方式形成自然的嵌套结构，类似于文件系统，同时确保无缝互操作性。该方法适用于任何现代构建工具和语言，从单体应用扩展到微服务。

API 和 SPI 用于数据抽象

使用 API-SPI 模式将核心业务逻辑与基础设施分离。API 是应用暴露的契约（如 CRM 接口）。SPI 是外部提供者的契约（Postgres 用于存储，TigerBeetle 用于支付）。

主要优势：

• 核心逻辑独立于特定数据库或服务。
• 无需重建核心即可更换实现。
• 单次引导过程支持多个提供者。

图示中，core 位于 api 和 spi 之间，基础设施组件实现 SPI。

引导组件用于应用组装

构建一个即插即用的引导组件作为依赖。它在应用上下文中将 SPI 实现连接到 API。现代框架自动解析依赖；在纯语言中，使用构建配置。

示例：CRM 引导组件通过共享上下文连接 crm/core 和 payments/core。这简化部署——只需添加依赖，即可运行。

演进到微服务

为独立扩展，拆分单体：

• 提取独立的 CRM 和支付应用。
• 在 CRM 中添加 rest-client，通过 HTTP 实现支付 API。
• 在支付中添加 rest-server，通过引导代理到 payments/core。
• 在 rest-common 中共享通用 DTO。
• 将客户端包装在 CRM 的引导组件中。

结果：有界上下文的集群，组件独立扩展。

平台组件

提取共享解决方案到平台，遵循 DRY 原则：

• Postgres 和 TigerBeetle 配置。
• REST 客户端/服务器通信。
• 认证、异步/同步消息传递和存储。

平台减少重复：组件即插即用现成配置。从基础到企业级解决方案，实现最大复用。

优势与治理

组件根据康威定律强制清晰边界：分配给团队并跟踪交互。

生命周期管理：小型组件易于替换和迁移。

保持需求导向：抽象让你基于 KPI（性能、成本）选择技术栈，而非习惯。

何时使用

从第一天起采用：从原型到分布式系统。适用于任何构建工具，可扩展到仓库和团队。避免“大泥球”——组件实现平滑演进。

关键要点：

• 细粒度目录作为部署和责任单元。
• API/SPI 用于与基础设施解耦。
• 引导组件用于自动上下文组装。
• 平台实现最大 DRY 和复用。
• 无需核心重构，即可无缝从单体过渡到微服务。

— Editorial Team