Load an order with lines and payments for a domain command without creating a cartesian product.

An order command needs the tracked Order, all Lines, and all Payments before applying a domain operation. Two sibling collection includes create a large cross product in one SQL query. Implement a deliberate split-query load.

An order with 20 lines and 10 payments should not produce 200 joined result rows just to reconstruct one aggregate.

• Keep tracking because the command modifies the aggregate.
• Require exactly one order by id.
• Use split query explicitly rather than a global surprise.
• State when a transaction or different read model is needed for consistency.

I keep the aggregate load explicit and tracked, but split the sibling collections into separate SQL commands to avoid cartesian multiplication. Split queries trade one huge result for several commands. If concurrent changes between those commands would violate the operation's assumptions, I would use an appropriate transaction or redesign the command around narrower data.

public static async Task<Order> LoadOrderForCommandAsync(
    AppDbContext db,
    Guid orderId,
    CancellationToken cancellationToken)
{
    return await db.Orders
        .Include(order => order.Lines)
        .Include(order => order.Payments)
        .AsSplitQuery()
        .SingleAsync(
            order => order.Id == orderId,
            cancellationToken);
}

The provider issues one query for the order and additional queries for included collections. Total transferred rows are usually far lower than a cross product, but round trips increase. Measure both shapes with realistic collection sizes and confirm the command truly needs the full tracked aggregate.

• The order has no payments yet.
• One collection is tiny and the other is very large.
• A related row changes between split commands.
• The command could be implemented as a narrow conditional update instead.

• Compare command count and transferred rows for single and split forms.
• Run with realistic collection cardinalities.
• Verify changes to loaded entities are saved because tracking remains enabled.
• Test the not-found path from SingleAsync.

• Adding AsNoTracking to an aggregate that will be modified.
• Assuming split queries are always faster.
• Ignoring consistency between multiple commands.
• Loading the full aggregate when a set-based update would enforce the rule better.