Information Expert模式是否与Service Layer模式存在矛盾？

两者本质不存在冲突，是分层架构中不同层级的互补设计规则，核心差异是适用场景和职责边界不同：

• 首先明确两个模式的核心设计目标

  Information Expert 是领域层的设计规则：核心要求是和单个领域对象自身状态强相关的原子逻辑必须放到类内部实现，避免对外暴露不必要的内部字段，同时保证同一份逻辑只有一处实现。
  举个实际场景：Order 类包含了订单关联的商品明细、单价、优惠规则，那计算订单应付总额的方法calculateFinalPrice()就应该定义在Order内部，外部不需要知道订单的明细构成、优惠计算规则，直接调用方法就能拿到结果。如果把这个逻辑放到Service里，就需要把Order的所有明细、优惠字段都对外暴露，后续修改优惠规则的时候还要改所有调用的Service代码，明显违反开闭原则。
  Service Layer 是应用层的设计规则：核心职责是编排跨领域对象、跨外部依赖的业务流程，本身不实现任何单领域对象的原子状态处理逻辑。

• 你感知到的冲突本质是常见的Service层误用：很多项目里把所有业务逻辑都塞到Service中，领域对象退化成只有get/set方法的贫血模型，这种用法才是违反Information Expert规则的，和模式本身的设计无关。
• 我们可以用完整的下单流程举例说明两者的配合：
  业务需求：用户下单后需要扣减商品库存、生成订单、增加用户积分、发送下单通知
  • 符合Information Expert规则的领域层逻辑：
    • Stock.deduct(goodsId, purchaseCount)：库存类自己实现扣减逻辑，内部判断库存是否足够，不够就抛出异常
    • Order.calculateFinalPrice()：订单类自己实现总价计算
    • User.addPoints(orderAmount)：用户类自己实现积分增加的规则（比如满100送10积分这类逻辑）
  • 属于Service层的流程编排逻辑：
    • 开启数据库事务
    • 调用Stock.deduct()方法完成库存扣减
    • 调用Order的构造方法生成订单实例，调用calculateFinalPrice()计算总价后存入数据库
    • 调用User.addPoints()给下单用户增加对应积分
    • 提交事务，异步调用通知服务发送下单成功提醒
      按照这个规则拆分后，两个模式各司其职，既保证了领域逻辑的内聚，也保证了业务流程的清晰可维护。

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