Hexagonal架构下Book类calculateScore方法应放Domain层还是Service中

核心判断逻辑 #

如果*「图书评分计算规则」属于业务域对图书实体的固有业务定义*（全业务场景下评分规则统一、计算仅依赖图书自身属性），优先选方案1将score()方法放在Domain层的Book实体中，这是充血领域模型的标准实践，核心目的是避免核心业务逻辑泄露到外层，保证领域层的内聚性。

两种方案的适用场景 #

• 存在以下任意一种情况时，选择方案2将评分逻辑抽为Application层的ScoreService：
  • 评分规则有多套并行适配需求：比如C端用户展示、商家后台管理、第三方渠道同步各自采用不同的评分规则，后续还会持续新增规则版本
  • 评分计算依赖领域层外的资源：比如扣减阈值X、扣减分值Y是存储在配置中心的动态参数，或者计算时需要调用其他领域的服务能力
  • 评分计算是特定业务用例的专属逻辑：比如只有执行图书上架、排行榜更新这类特定操作时才需要计算评分，不属于图书实体自带的通用属性
• 存在以下情况时，选择方案1将逻辑放在Domain层的Book实体中：
  • 评分是图书的固有属性，全业务场景下评分规则统一
  • 计算评分仅需要用到Book自身的属性（页数、基础分、出版时间等），不依赖外部资源
  • 规则变动概率极低，就算调整也是全业务域统一升级，不需要多版本规则共存

兼顾内聚性和扩展性的优化方案 #

如果担心后续规则变动会侵入Book实体的稳定逻辑，可以在Domain层定义评分策略接口，Book实体的评分方法依赖该策略实现，既符合领域层内聚的要求，又支持规则的灵活扩展：

package com.xxx.domain;

// 领域层定义评分策略抽象
public interface ScoreCalculatePolicy {
    Double calculate(Book book);
}

public class Book {
    public Double score(ScoreCalculatePolicy policy) {
        return policy.calculate(this);
    }
}

不同的评分规则可以作为该接口的不同实现放在Domain层或者Application层，不需要修改Book实体本身的代码，也避免了核心业务逻辑外泄。

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