.NET系统领域层与应用层职责划分及应用层处理器最佳实践

一、应用层处理器设计最佳实践 #

• 采用**命令/查询职责分离（CQRS）**模式：拆分读写操作，命令处理器负责状态变更，查询处理器负责数据读取，每个处理器职责单一，便于维护和测试。
• 绑定具体业务用例：每个处理器对应一个特定业务场景（如CreateOrderProcessor、CancelSubscriptionProcessor），而非通用CRUD处理器，确保逻辑聚焦。
• 依赖抽象而非实现：处理器依赖领域层定义的接口（如IOrderRepository），具体实现由基础设施层提供，降低耦合度。
• 负责跨领域协作编排：当业务逻辑需要协调多个领域实体或服务时，由应用层处理器组织流程，比如下单时串联库存校验、支付调用等环节。

二、业务逻辑：领域实体内聚 vs 应用层处理器 #

• 核心业务逻辑必须放在领域实体：比如订单的状态流转规则（仅未支付订单可取消）、金额计算、库存扣减合法性校验等，这些属于领域本身的固有规则，封装在实体内部可保证行为完整性，避免贫血模型。
  示例代码：

  public class Order
  {
      public OrderStatus Status { get; private set; }
  
      public void Cancel()
      {
          if (Status != OrderStatus.Created && Status != OrderStatus.Paid)
              throw new InvalidOperationException("仅未支付或已创建的订单可取消");
          Status = OrderStatus.Canceled;
          // 触发领域事件（如OrderCanceledEvent）
      }
  }
  

• 编排型、跨领域逻辑放在应用层处理器：比如创建订单的完整流程——接收请求、校验用户权限、调用订单实体创建方法、协调库存扣减、记录操作日志等，这类流程性编排不属于单个领域实体的核心规则，适合放在应用层处理器中。
  示例代码：

  public class CreateOrderProcessor
  {
      private readonly IOrderRepository _orderRepo;
      private readonly IInventoryService _inventoryService;
      private readonly IUserPermissionChecker _permissionChecker;
  
      public CreateOrderProcessor(IOrderRepository orderRepo, IInventoryService inventoryService, IUserPermissionChecker permissionChecker)
      {
          _orderRepo = orderRepo;
          _inventoryService = inventoryService;
          _permissionChecker = permissionChecker;
      }
  
      public async Task<Guid> Process(CreateOrderCommand command)
      {
          // 权限校验（应用层逻辑）
          if (!await _permissionChecker.HasPermission(command.UserId, "CreateOrder"))
              throw new UnauthorizedAccessException("无创建订单权限");
  
          // 库存校验（跨领域协作，应用层编排）
          var stockAvailable = await _inventoryService.CheckStock(command.ProductId, command.Quantity);
          if (!stockAvailable)
              throw new InvalidOperationException("库存不足");
  
          // 领域实体核心逻辑
          var order = Order.Create(command.UserId, command.ProductId, command.Quantity);
          await _orderRepo.AddAsync(order);
          await _orderRepo.SaveChangesAsync();
  
          // 触发后续操作
          await _inventoryService.DeductStock(command.ProductId, command.Quantity);
  
          return order.Id;
      }
  }
  

三、应用层与领域层的功能边界划分 #

• 领域层：
  • 负责表达核心业务规则与领域概念，包含实体、值对象、领域服务、领域事件。
  • 不依赖上层（应用层）或基础设施层的具体实现，仅依赖自身抽象。
  • 聚焦"业务是什么"，即业务的本质规则，比如"订单必须关联用户ID才能创建"、"库存扣减不能超过当前库存"。
• 应用层：
  • 负责业务流程编排，协调领域实体、领域服务与基础设施服务完成具体业务用例。
  • 处理权限校验、日志记录、外部系统交互（如调用第三方支付接口）等非核心但必要的流程。
  • 聚焦"业务怎么做"，即组合领域层能力完成用户发起的具体请求，比如"用户提交订单后，需依次完成权限校验、库存检查、订单创建、库存扣减"。
• 边界判断原则：若一段逻辑脱离当前领域实体就无法成立，属于领域层；若逻辑是串联多个领域能力完成特定场景，属于应用层。

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