ASP.NET Core洋葱架构微服务领域服务与事务实现咨询

洋葱架构下的领域服务按职责和依赖属性严格划分为两类，归属层级完全固定：

• 纯核心领域服务：封装无外部依赖的核心业务规则、业务计算逻辑，包括单聚合内部无法承载的跨实体规则、跨聚合纯业务判断逻辑，必须实现在领域层（Domain层）。这类服务只依赖领域层内的聚合、值对象、领域事件抽象，不引用任何上层服务、基础设施实现，是整个系统业务逻辑的核心载体。比如订单实付金额计算、优惠券核销门槛校验、会员等级权益匹配规则都属于这类。
• 领域能力适配服务：封装需要对接基础设施的领域操作，比如聚合持久化、跨上下文领域数据查询这类操作，接口定义放在领域层，具体实现放在基础设施层（Infrastructure层）。实现类依赖领域层定义的抽象做依赖注入，保证核心领域逻辑不会向外层泄露。

你的理解完全正确。
应用服务属于应用层（Application层），唯一职责是用例流程编排：接收前端/外部请求、做基础参数合法性校验、拉取所需的聚合根和领域服务、按用例流程调度执行、管控事务提交回滚、组装返回结果。应用服务里绝对不能写核心业务计算、业务规则判断类的代码。
举个很常见的反例：如果把订单满减计算逻辑写在应用服务里，后续后台改价、批量下单、预售转正式单等多个入口需要复用规则时，很容易出现逻辑重复、规则不一致的问题，所有和业务规则相关的判断、计算必须下沉到领域层。

这类逻辑不要全堆到某一层，按逻辑属性拆分处理即可：

• 如果事务流程包含核心业务计算、跨聚合业务规则校验，比如下单场景需要同时操作订单、库存、优惠券三个聚合，其中涉及的库存扣减规则校验、优惠券锁定规则判断、订单金额联动计算都属于核心业务逻辑，这部分的逻辑协调和规则实现放在领域层的核心领域服务中，应用层只负责开启事务、调度对应领域服务执行、根据执行结果提交或回滚事务。
• 如果事务流程仅涉及多聚合的状态流转、无复杂业务规则计算，比如批量更新商品上下架状态、批量标记已读通知这类场景，可以直接放在应用服务中做流程编排，事务边界由应用层统一配置的工作单元（UnitOfWork）管控即可。

内容的提问来源于stack exchange，提问作者M-AMIN