微服务架构下，复杂业务逻辑应部署在哪个层级？

那种仅包含API层和Repository层的微服务结构，确实是很多入门文章里用来演示简单CRUD场景的简化模式，但面对复杂业务逻辑时，完全不用被这种两层结构限制，你可以通过以下几种方式处理：

• 在微服务内部新增业务逻辑层
  微服务并没有强制要求只能两层，只要业务逻辑属于当前服务的核心职责，就应该在API层和Repository层之间加上业务逻辑层，结构变成：

  Rest API Controller <-> Business Logic Layer <-> Repository Layer
  

  比如订单服务里的订单状态流转校验、金额计算、超时自动取消这类复杂逻辑，就该放在订单服务的业务逻辑层中，这样既能保持服务的高内聚，也方便针对业务逻辑单独做单元测试和维护。

• 拆分独立的业务逻辑服务
  如果某段复杂逻辑是多个微服务都会用到的通用能力，或者本身规则复杂度极高、可以独立成为一个职责单一的服务，那就把它拆成独立服务。比如电商场景中的优惠规则计算、风控校验逻辑，完全可以做成单独的优惠服务、风控服务，其他需要用到这些逻辑的服务通过调用其API来完成相关操作，避免重复代码，也能集中维护复杂规则。

• 基于领域驱动设计（DDD）拆分限界上下文
  如果业务逻辑复杂到涉及多个领域模型，建议用DDD的限界上下文思路来拆分微服务，每个微服务对应一个限界上下文，负责该上下文内的所有业务逻辑。比如电商中的订单上下文、库存上下文、支付上下文，每个上下文的服务都包含自己的业务逻辑层，处理该领域内的复杂规则，跨上下文的交互通过领域事件或者API调用实现，确保每个服务只关注自己领域内的业务，避免逻辑混乱。

核心原则是，微服务的设计要围绕单一职责和高内聚低耦合，层数只是实现手段，不用被固定结构束缚。

内容的提问来源于stack exchange，提问作者Just code