I am designing a DDD-based travel planning system in Java, following a layered architecture:

UI Layer → Handles user interactions.

Application Layer → Contains business logic and orchestrates domain operations.

Domain Layer → Defines core business rules and aggregates.

Infrastructure Layer → Handles persistence and external system interactions.

The domain layer serves as the bridge between the application and infrastructure layers.

The Problem: In my TravelPlan aggregate, I need to associate MemberTravelPlan with TravelPlan.

However, I'm unsure whether TravelPlan should store a single MemberTravelPlan or a list of MemberTravelPlan.

MemberTravelPlanEntity is an association entity that connects MemberEntity and TravelPlanEntity.

A TravelPlan typically contains multiple MemberTravelPlan records. However, in some cases, I only need one MemberTravelPlan (e.g., retrieving the host or primary organizer).

Other times, I need all MemberTravelPlan instances (e.g., calculating total participants).

My Questions: Should I store MemberTravelPlan as a List, even when I only need one instance?

Should I use a single MemberTravelPlan field when I know only one record is relevant?

What is the best DDD practice for handling cases where an entity is sometimes one-to-one and sometimes one-to-many?

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();
    }
}

I am designing a DDD-based travel planning system in Java, following a layered architecture:

UI Layer → Handles user interactions.

Application Layer → Contains business logic and orchestrates domain operations.

Domain Layer → Defines core business rules and aggregates.

Infrastructure Layer → Handles persistence and external system interactions.

The domain layer serves as the bridge between the application and infrastructure layers.

The Problem: In my TravelPlan aggregate, I need to associate MemberTravelPlan with TravelPlan.

However, I'm unsure whether TravelPlan should store a single MemberTravelPlan or a list of MemberTravelPlan.

MemberTravelPlanEntity is an association entity that connects MemberEntity and TravelPlanEntity.

A TravelPlan typically contains multiple MemberTravelPlan records. However, in some cases, I only need one MemberTravelPlan (e.g., retrieving the host or primary organizer).

Other times, I need all MemberTravelPlan instances (e.g., calculating total participants).

My Questions: Should I store MemberTravelPlan as a List, even when I only need one instance?

Should I use a single MemberTravelPlan field when I know only one record is relevant?

What is the best DDD practice for handling cases where an entity is sometimes one-to-one and sometimes one-to-many?

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();
    }
}

• domain-driven-design

1 Answer 1

In Domain-Driven Design, you should model your aggregate to closely reflect the real-world domain and the invariants you need to enforce.

In your travel planning system, a TravelPlan is an aggregate that can involve multiple associated MemberTravelPlan records(even if in some cases you only have one).

So I think you should store the MemberTravelPlan as a List within your TravelPlan aggregate.