First, thanks for reading :)

If you've correctly modeled your Domain, then it's rarely possible for you to get stuck on this question.

If that happens, it means there’s a real business issue or a misunderstanding of the Domain.

As a Software Engineer, it's not uncommon to bring practical cases of inconsistencies to Domain experts.

These inconsistencies are first resolved in real life and then modeled in code.

In the example from this post, the FrontWheelAggregate ensures its integrity and then we produce a model for the BikeAggregate.

If the BikeAggregate cannot guarantee consistency because the wheel hasn’t been manufactured beforehand, then the real-world process hasn’t been followed.

If your point was more about how to "technically" ensure that different aggregates are persisted within the same process, then yes, a transaction system does the job perfectly :)

But it's not necessarily required to guarantee consistency "across all aggregates".

Imagine a person manufacturing wheels and storing them.

Another person later assembles the wheels onto the bike. If they notice an inconsistency, they probably have a procedure to handle it.

If everything is modeled to align with the real-world business process, consistency issues are already accounted for by the Domain itself.

In this case, the right question to ask would be:

"What happens if there is a consistency issue when assembling the wheel onto the bike?"

A Domain expert would answer with a list of procedures for each inconsistency scenario.

That’s what should be modeled in your BikeAggregate at the wheel assembly level.

Our approach to consistency is often too technical because we are used to handling it that way.

With DDD, we can take a completely different approach. The key is to align as closely as possible with the domain.

I hope this makes sense and answers your question :)