There are two different approaches to untangle the situation.

1. Treat Sandwich as a part of Order aggregate, not as a separate aggregate
2. Remove the reference from Sandwich to Order and follow the one aggregate per transaction rule

If every Sandwich instance must belong to an Order (or a Cart) under your business rules, then I think the 1st option is the way to go.

If you want to save the customized Sandwiches and reuse them in the future, like for easy re-ordering, then the 2nd option would be better.

An Aggregate is a logical boundary of objects which can be built independently. If you can't follow the one aggregate per one transaction rule, I think it's better to rethink the model instead of bypass the rule.

There are two different approaches to untangle the situation.

1. Treat Sandwich as a part of Order aggregate, not as a separate aggregate
2. Remove the reference from Sandwich to Order and follow the one aggregate per transaction rule

If every Sandwich instance must belong to an Order (or a Cart) under your business rules, then I think the 1st option is the way to go.

If you want to save the customized Sandwiches and reuse them in the future, like for easy re-ordering, then the 2nd option would be better.

To determine if it's an aggregate or not, you have to answer the question: "Can a Sandwich exist without an Order or not ?"

An Aggregate is a logical boundary of objects which can be built independently. If you can't follow the one aggregate per one transaction rule, I think it's better to rethink the model instead of bypass the rule.