企业业务系统架构选型与渐进式演进

一句话理解

架构选型不是"微服务一定先进"，而是根据业务边界、规模、团队、交付周期、运维能力和一致性要求，在当前约束下选择总成本最低、还能继续演进的方案。

一、先判断问题，再选择架构

架构设计前先回答：

判断维度	需要确认的问题
业务边界	模块之间是否有清晰的职责边界？是否存在稳定的业务域？
规模	用户数、并发量、数据量和峰值是否已经超过单体承载能力？
团队	是否有足够的人力维护多个服务、部署链路和监控体系？
交付	项目是快速交付，还是需要多个团队长期独立迭代？
数据	模块之间是否强依赖同一事务？跨库一致性是否可接受？
运维	是否具备容器、服务发现、链路追踪、灰度发布等能力？
演进	哪些模块未来可能独立扩容或独立发布？

不要先决定"用微服务"，再反过来找理由。先把约束写清楚，结论才可解释。

二、三种架构形态

形态	特点	适用场景	主要代价
传统单体	一个应用、一个部署单元，模块边界较弱	小型系统、快速验证、业务简单	代码容易耦合，发布影响面大
模块化单体	一个部署单元，但按业务域分包、分层和隔离	企业内部系统、中等规模、交付优先	需要团队遵守模块边界
微服务	多个业务服务，独立部署和扩展	边界稳定、团队较大、模块需独立演进	调用、事务、部署、监控和运维复杂

模块化单体不是"没有架构"，而是在一个进程内维护清晰的业务边界。它可以是微服务之前的稳健阶段，也可以是长期合理的终态。

三、为什么企业内部系统不一定要微服务

以 SRM、ERP、政企办公等内部管理系统为例，常见约束是：

用户规模和并发量相对可控；
业务模块之间存在较强事务关联；
项目交付周期有限；
团队规模不大；
客户更关心稳定交付和问题响应；
多服务部署会增加运维和现场交付成本。

这类系统可以采用：

text 复制代码

Vue3 / React 前端
        ↓ HTTP/REST
Nginx
        ↓
Spring Boot 模块化单体
        ├── supplier      供应商
        ├── sourcing      寻源
        ├── purchase      采购订单
        ├── receiving     收货与质检
        ├── settlement    对账结算
        └── common        鉴权、日志、异常、导出
        ↓
MySQL + Redis + MQ

前后端分离、模块化和统一工程规范已经可以解决很多问题，不需要为了"架构先进"引入分布式事务和服务治理成本。

四、模块化单体怎么设计才不会变成大泥球

1. 按业务模块分包

不要只按 Controller、Service、Mapper 全局分成三个大目录，可以在业务域内保持分层：

text 复制代码

order/
├── controller/
├── service/
├── domain/
├── mapper/
└── dto/

2. 明确模块依赖方向

Controller 只处理协议、鉴权和参数校验；
Service 负责用例编排；
Domain 承载核心业务规则；
Mapper 负责数据访问；
模块之间通过明确的接口交互，不直接修改对方数据；
公共模块只放真正通用的能力，避免变成新的耦合中心。

3. 预留拆分边界

如果未来可能拆分，应提前做好：

模块自己的业务包和数据访问边界；
业务对象与外部 DTO 的隔离；
跨模块操作通过应用服务或领域事件；
不依赖对方内部表结构；
记录模块调用和消息契约。

五、什么时候适合拆成微服务

出现以下信号时，才考虑拆分：

某个模块需要独立扩容；
某个模块发布频繁，已经影响其他模块；
业务边界稳定，团队可以独立负责；
某个模块需要不同的技术栈或资源配置；
数据规模和访问模式明显不同；
故障隔离收益超过分布式复杂度。

拆分不是一次性重写，可以按以下路径演进：

text 复制代码

传统单体
  ↓ 整理依赖与模块边界
模块化单体
  ↓ 识别独立扩展/发布的稳定业务域
优先拆出边界清晰的服务
  ↓ 补齐注册、配置、监控、链路和发布能力
渐进式微服务

六、服务拆得过细会带来什么问题

一次业务请求跨越多个服务，链路变长；
网络超时、重试和熔断成为业务必须处理的问题；
跨服务事务需要最终一致性或分布式事务；
本地调试和测试成本增加；
发布、配置、监控和告警数量增加；
服务数量超过团队维护能力后，系统稳定性反而下降。

因此，服务拆分的原则不是"越细越好"，而是业务内高内聚、业务间低耦合、拆分后有独立收益。

七、DDD 在架构选型中的作用

DDD 不等于把项目目录改成 domain 就完成了。它的实际价值是帮助团队：

识别限界上下文；
建立统一语言；
找到聚合根和业务边界；
区分领域规则与技术实现；
决定哪些边界适合成为模块或服务。

例如采购系统可以识别：供应商、寻源、订单、收货质检、结算等业务上下文。是否拆成微服务，还要继续结合规模和运维约束判断。