我有一个用于获取用户档案的外部服务适配器，接口定义如下：

UserProfileDto getUserProfile(String profileId);

底层服务通过同一个参数支持多种标识符格式，例如：

userId
SIN::accountId
94::phoneNumber

由于该API接受通用的String类型参数，代码库中的调用方经常手动构造这些值：

getUserProfile("SIN::" + accountId);

或者

getUserProfile(countryCode + "::" + phoneNumber);

这导致标识符格式化逻辑分散在整个代码库中，且适配器支持的标识符类型不明确。从领域驱动设计（DDD）的角度来看，哪种建模方式更合适？我考虑了以下两种方案：

1. 暴露不同的语义化方法：

getUserProfileByUserId(String userId);
getUserProfileByAccountId(String accountId);
getUserProfileByPhoneNumber(String countryCode, String phoneNumber);

2. 保留单一方法但引入强类型查找对象：

getUserProfile(UserProfileLookup lookup);

在保持清晰业务边界且集中管理标识符转换逻辑的前提下，哪种方案更受青睐？

从DDD的核心原则（明确领域语义、集中领域逻辑、保持边界清晰）出发，两种方案各有适用场景，但强类型查找对象的方案（方案2）更符合DDD的建模思想，具体分析如下：

方案1：语义化方法的优缺点 #

• 优点：调用方代码可读性极强，一眼就能明确查询所用的标识符类型，无需额外理解格式规则。
• 缺点：
  • 扩展性差：新增标识符类型时必须在适配器中新增对应方法，类型越多接口越臃肿，违反开闭原则。
  • 边界模糊：适配器会因方法数量膨胀而承担过多语义职责，偏离“适配外部服务”的核心定位。

方案2：强类型查找对象的核心优势 #

• 集中管理转换逻辑：所有标识符到profileId的格式化逻辑都封装在UserProfileLookup中，彻底解决逻辑分散的问题。
• 明确领域语义：通过语义化的静态工厂方法（如byUserId、byAccountId）创建查找对象，调用方只能按规范方式构造，从根源避免格式错误，同时清晰展示所有支持的查找类型。
• 扩展性优异：新增标识符类型时，仅需给UserProfileLookup添加对应的创建方法，无需修改适配器核心接口，完全符合开闭原则。
• 保持适配器边界清晰：适配器核心方法保持单一，专注于与外部服务的交互，查找逻辑的语义与转换由领域对象承担，契合DDD“领域对象封装领域逻辑”的要求。

参考实现示例 #

UserProfileLookup可设计为不可变值对象，示例代码如下：

public class UserProfileLookup {
    private final String profileId;

    private UserProfileLookup(String profileId) {
        this.profileId = profileId;
    }

    public static UserProfileLookup byUserId(String userId) {
        return new UserProfileLookup(userId);
    }

    public static UserProfileLookup byAccountId(String accountId) {
        return new UserProfileLookup("SIN::" + accountId);
    }

    public static UserProfileLookup byPhoneNumber(String countryCode, String phoneNumber) {
        return new UserProfileLookup(countryCode + "::" + phoneNumber);
    }

    public String getProfileId() {
        return profileId;
    }
}

适配器实现简化为：

public UserProfileDto getUserProfile(UserProfileLookup lookup) {
    return externalService.getUserProfile(lookup.getProfileId());
}

这种实现既保证了调用方代码的语义清晰度，又完全集中了转换逻辑，同时维持了适配器的简洁性，完美契合DDD的建模要求。

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