第一坑：把“战略设计”当成 PPT 表演，画完就扔

很多团队做架构设计，第一步就是打开Visio画微服务架构图、业务流程图、数据流图。图画得漂漂亮亮，评审会上大家点头通过，然后……就没有然后了。开发团队拿到图还是不知道该从哪个包开始写代码，战略设计和战术落地之间出现了巨大的断层。

破局思路：让战略设计的产物直接“长出”代码骨架。 何辉实战营的一个核心逻辑是：战略设计阶段梳理出的子域划分、限界上下文，必须能一对一映射到工程结构中的包划分和模块边界。订单域在销售上下文和物流上下文中即使名称相同，其属性和行为也因上下文而不同——这种设计若不能体现在Java包的命名和依赖关系里，战略设计就只是一堆好看的图片。画图是为了指导建工程，不是为了完成评审任务。

第二坑：微服务拆分“按团队切”而不是“按能力切”

这是外包项目和自研项目中最常见的灾难。为了快速分工，团队按“登录模块”、“订单模块”、“支付模块”来切分服务，看似清晰，实则埋下了服务间调用混乱、分布式事务泛滥的隐患。甚至出现过所有服务共用同一个数据库的情况——物理层数据都不隔离，拆微服务的意义何在？

破局思路：横向分层拆分优先于纵向按模块拆分。 真正的微服务拆分要回答的是：哪些能力是底层可复用的？哪些流程是上层易变的？横向拆分以数据驱动为核心——如果供应商数据在ERP、SRM、采购、合同等多个系统落地使用，就应该下沉为独立的“供应商中心”，暴露统一API接口；原来的上层业务系统不再涉及任何供应商业务，按需调用即可。这种“能力中心层 + API接口 + 上层应用”的模式，是SOA思想与微服务架构的真正融合。

第三坑：用“贫血模型”写业务逻辑，所有规则都堆在 Service 里

很多Java项目的标准写法是：一个Entity只有getter/setter（贫血模型），所有的业务校验、状态流转、计算逻辑全部塞进Service层。结果一个Service类动辄几千行，牵一发而动全身。业务规则变更时，开发人员在几百个方法里大海捞针。

破局思路：拥抱“充血模型”，让领域实体自己管自己的事。 将业务规则、状态流转逻辑封装在领域实体和聚合根内部，确保业务行为与数据状态的高度统一。而在处理长链路复杂流程时，引入流程编排引擎（如Camunda或状态机模式），将流程编排与原子能力执行分离。业务规则变了，改领域实体；流程顺序变了，改编排配置——两者互不干扰，才是可维护的架构。

第四坑：只关心“功能跑通”，不关心“可观测性和一致性”

架构设计文档里写满了“高并发”、“高性能”，但上线后发现：跨域调用的分布式事务经常出现数据不一致；生产环境出了问题，链路追踪日志七零八落，查了半天不知道是哪个环节挂了。代码跑通了，但系统成了黑盒。

破局思路：把“治理能力”当作架构设计的必选项，而非可选项。 从第一天起就要规划全链路可观测性——利用分布式链路追踪将跨多个业务域的请求串联起来。对于跨域调用的数据一致性，采用Saga或TCC等柔性事务方案，替代强一致性数据库事务，在保证高可用的同时确保数据的最终一致性。功能决定系统能不能上线，治理决定系统能活多久。

结语：业务架构落地，始于图纸，终于代码

何辉实战营的一个鲜明特征是将“架构CR”（架构代码评审）写入了课程的正循环流程。这意味着，架构设计的交付物不是PPT，而是每一行经过评审、能跑通、可观测、能治理的真实代码。

真正的架构师思维，是把业务域划分变成包结构，把流程编排变成状态机配置，把高并发方案变成实实在在的缓存策略和降级预案。画图是起点，代码落地才是终点。 当你的架构图能指导团队写出清晰、分层合理、可维护的Java代码时，你才算真正跨越了从“开发者”到“架构师”的那道门槛。