企业官网建设流程全解析

一句话理解

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

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

架构设计前先回答：

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

二、三种架构形态

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

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

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

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

这类系统可以采用：

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

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

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

1. 按业务模块分包

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

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

2. 明确模块依赖方向

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

3. 预留拆分边界

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

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

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

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

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

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

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

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

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

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

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

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

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

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