DDD领域对象内调用AddressValidationAdapter的最佳实践咨询

核心诉求很明确：在六边形架构+DDD的约束下，让Address值对象既能复用域内默认验证逻辑，又能支持外部通过AddressValidationAdapter扩展/替换验证规则，同时得保持值对象的纯净性和架构分层原则。下面逐一分析你的选项，并给出最优实践：

1. 构造函数注入依赖？不推荐 #

值对象的核心是不可变、仅依赖自身属性，把AddressValidationAdapter塞进构造函数完全违背这一特性：

• 会让Address的实例化绑定外部服务，破坏“值对象由属性唯一确定”的本质；
• 每次创建Address都要传适配器，大幅增加使用成本，批量创建场景下尤其麻烦。

2. 全局/静态上下文？谨慎使用 #

静态注册表、全局工厂这类方式能解决依赖传递问题，但缺点很突出：

• 静态状态会导致测试隔离困难，没法独立验证不同适配器的逻辑；
• 全局状态容易引发并发问题，多租户或动态切换规则的场景下风险更高；
• 不符合六边形架构“端口-适配器”原则，把外部依赖硬编码进域层，降低扩展性。
  如果一定要用，建议用线程安全的静态注册表，且仅在启动时初始化，避免运行时动态修改。

3. 事件驱动方式？过度设计，没必要 #

发布ValidationEvent再订阅结果的方式，适合异步、跨域或多系统协同的复杂验证场景，但Address这类简单值对象的验证通常是同步即时的：

• 会凭空增加复杂度，验证失败本应直接阻止Address实例化，异步事件做不到这一点；
• 事件驱动的松散耦合反而会让验证逻辑的执行顺序变得不可控。

4. 编排服务？符合架构原则，合理选择 #

你担心这种方式不符合DDD风格，但在六边形架构中，应用服务（Application Service） 本来就负责编排域对象与外部适配器的交互，这完全合理：

• 把复杂业务验证从Address中剥离，Address只负责基础格式校验（比如非空、邮编格式合法），这部分是域内核心规则，不允许外部替换；
• 应用服务作为端口，接收外部传入的适配器（或从DI容器获取），在创建Address前调用适配器完成业务验证，通过后再实例化Address。

最优实践：分层验证+适配器注入到应用服务 #

具体步骤 #

1. Address值对象保留基础校验：只处理与自身属性强绑定的规则（如街道非空、邮编格式正确），这部分是域内核心逻辑，不对外开放修改；
2. 定义域层端口：在域层的Ports目录下创建AddressValidationAdapter接口，包含validate(Address address): ValidationResult方法；
3. 实现默认验证器：作为域内适配器实现上述接口，处理通用业务验证规则；
4. 应用服务编排流程：
   • 在创建Address的应用服务方法中，通过构造函数注入AddressValidationAdapter（默认用域内实现，外部可通过DI替换为自定义实现）；
   • 先调用适配器完成业务验证，通过后再实例化Address；
   • 验证失败直接抛出域异常或返回错误结果。

伪代码示例 #

// 域层端口
public interface AddressValidationAdapter {
    ValidationResult validate(Address address);
}

// 域内默认适配器实现
public class DefaultAddressValidationAdapter implements AddressValidationAdapter {
    @Override
    public ValidationResult validate(Address address) {
        if (!isValidRegion(address.getRegion())) {
            return ValidationResult.failure("区域不合法");
        }
        return ValidationResult.success();
    }

    private boolean isValidRegion(String region) {
        // 实现区域合法性校验逻辑
        return region != null && region.length() <= 20;
    }
}

// Address值对象
public class Address {
    private final String street;
    private final String region;
    private final String zipCode;

    private Address(String street, String region, String zipCode) {
        // 基础校验，不允许外部替换
        if (street == null || street.isBlank()) {
            throw new DomainException("街道不能为空");
        }
        if (!isValidZipCode(zipCode)) {
            throw new DomainException("邮编格式错误");
        }
        this.street = street;
        this.region = region;
        this.zipCode = zipCode;
    }

    // 静态工厂方法，仅负责基础校验后的实例化
    public static Address create(String street, String region, String zipCode) {
        return new Address(street, region, zipCode);
    }

    // 基础格式校验逻辑
    private boolean isValidZipCode(String zipCode) {
        return zipCode != null && zipCode.matches("\\d{6}");
    }

    // getter方法
    public String getRegion() { return region; }
}

// 应用服务
public class AddressApplicationService {
    private final AddressValidationAdapter validationAdapter;

    // 构造函数注入适配器，外部可替换
    public AddressApplicationService(AddressValidationAdapter validationAdapter) {
        this.validationAdapter = validationAdapter;
    }

    public Address createValidatedAddress(String street, String region, String zipCode) {
        // 先完成基础校验并实例化Address
        Address address = Address.create(street, region, zipCode);
        // 调用适配器做业务验证
        ValidationResult result = validationAdapter.validate(address);
        if (!result.isSuccess()) {
            throw new DomainException(result.getMessage());
        }
        return address;
    }
}

方案优势 #

• 符合六边形架构：域层定义端口，外部通过适配器实现扩展，严格遵循依赖倒置原则；
• 保持DDD值对象纯净性：Address只关注自身属性与核心规则，不依赖外部服务；
• 灵活性高：外部可通过DI替换AddressValidationAdapter实现，无需修改域层代码；
• 职责清晰：应用服务负责编排验证与实例化，域层专注核心业务规则，边界明确。

补充：若必须在Address内部调用适配器？ #

如果业务场景要求必须在Address内部触发验证（比如Address的某些行为需要即时验证），可以用静态工厂方法结合适配器注册表的方式：

• 在域层提供AddressValidationRegistry类，允许注册AddressValidationAdapter，默认注册域内实现；
• Address的静态工厂方法或validate方法中，从注册表获取适配器完成验证；
• 注意注册表要保证线程安全，且仅在启动时配置。
  但这种方式会引入全局状态，需要权衡测试与扩展性的影响。

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