复杂系统，从清晰的边界开始

先理解业务，再选择架构

系统的复杂度往往来自职责混杂。设计初期，先梳理核心概念、数据归属和业务约束，比决定使用多少个服务更有价值。把用户、项目与权限等规则放在明确的领域模块内，可以让变化保持局部。

复杂在系统内部，清晰留给使用者。

模块化单体是一个务实的起点

单一部署单元不意味着没有边界。模块之间通过明确接口协作，避免直接访问其他模块的内部数据。保持依赖方向清晰，并为关键边界编写测试，就能在较低的运维成本下保留演进空间。

让拆分由真实需求驱动

当某个模块确实需要独立伸缩、独立发布或独立的团队所有权时，再评估拆分。拆分前需要同时考虑网络故障、数据一致性、观测和回滚成本。好的架构不是服务数量更多，而是变化发生时更容易理解和验证。