DDD领域对象应关联单个对象还是集合？旅行规划系统实践疑问

背景说明 #

我正在用Java设计基于DDD的旅行规划系统，采用分层架构：

• UI层：处理用户交互
• 应用层：包含业务逻辑并编排领域操作
• 领域层：定义核心业务规则和聚合根
• 基础设施层：处理持久化和外部系统交互
  领域层作为应用层与基础设施层的桥梁。

当前遇到的模型设计问题：
在TravelPlan聚合中，需要关联MemberTravelPlan（关联实体，用于连接Member和TravelPlan）。一个TravelPlan通常对应多条MemberTravelPlan记录，但部分场景只需单个实例（比如获取主持人/主要组织者），另一些场景需要全部实例（比如计算总参与人数）。不确定TravelPlan该存储单个MemberTravelPlan还是List<MemberTravelPlan>，具体疑问如下：

1. 即使只需要单个实例，也应该将MemberTravelPlan存储为List吗？
2. 当明确仅需一条记录时，是否应该用单个MemberTravelPlan字段？
3. 对于实体有时一对一、有时一对多的场景，DDD的最佳实践是什么？

当前TravelPlan的实现代码：

public record TravelPlan(TravelPlanInfo travelPlanInfo, List<MemberTravelPlan> memberTravelPlans) {

    @Builder()
    public TravelPlan {
    }

    public void validateCreatedAndCloseTime() {
        if (travelPlanInfo.createTime().isBefore(travelPlanInfo.closeTime())) {
            throw new IllegalArgumentException("exception");
        }
    }

    public int calCurPeopleCount() {
        return memberTravelPlans.stream()
                .mapToInt(memberTravelPlan -> memberTravelPlan.adultCount() + memberTravelPlan.childCount() + memberTravelPlan.infantCount())
                .sum();
    }
}

问题解答 #

1. 即使只需要单个实例，也应该将MemberTravelPlan存储为List吗？ #

应该。从领域模型的本质来看，TravelPlan与MemberTravelPlan的核心关联关系是一对多（常态下对应多条记录），单个实例的需求只是业务场景中的查询特例，而非模型本身的结构约束。用List存储能统一模型的基础结构，避免因场景差异导致模型分裂，同时兼容未来可能的业务变化（比如原本的"仅需单个"场景后续允许新增关联记录）。

另外，你现有代码中的calCurPeopleCount方法已经依赖List计算总人数，保持List存储能让领域方法的实现更连贯，无需额外处理单个字段和集合的切换逻辑。

2. 当明确仅需一条记录时，是否应该使用单个MemberTravelPlan字段？ #

不建议单独添加单个字段。如果业务中需要获取主持人这类特定角色的MemberTravelPlan，应该通过领域方法从List中筛选，而非在聚合根中单独存储。比如在TravelPlan中新增方法：

public Optional<MemberTravelPlan> getOrganizer() {
    return memberTravelPlans.stream()
            .filter(mtp -> mtp.isOrganizer()) // 假设MemberTravelPlan有标识组织者的属性
            .findFirst();
}

这样既保持了模型结构的统一性，又能满足特定场景的查询需求，同时避免了数据冗余（单个字段和List可能出现数据不一致的问题）。

3. 对于实体有时为一对一、有时为一对多的场景，DDD的最佳实践是什么？ #

核心原则是基于领域本质定义模型，而非场景特例，具体做法包括：

• 优先识别关联关系的常态：如果大多数场景是一对多，就按一对多设计模型，一对一的需求通过领域方法或查询逻辑实现。
• 避免因临时场景修改模型结构：场景需求是多变的，但领域模型的核心结构要稳定。如果为了某个临时的一对一场景修改聚合根字段，会导致模型复杂度上升，后续维护成本增加。
• 用领域方法封装场景逻辑：将特定场景的查询、筛选逻辑封装在聚合根内部，对外暴露清晰的业务方法（比如getOrganizer()、calCurPeopleCount()），而不是让外部直接操作内部集合或字段。
• 坚守聚合边界：确保MemberTravelPlan属于TravelPlan聚合的一部分，这样聚合根能维护关联关系的一致性（比如新增MemberTravelPlan时验证规则，删除时更新人数统计等）。

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