How do you deal with large and complex aggregate roots that span multiple bounded contexts?

I don't encounter the problem of dealing with large and complex aggregate roots because I don't use aggregates. To me, aggregates are a complicated abstraction meant to represent "the current state of the system." Instead, I rely on independent read models populated by domain events. This approach allows me to check the current state of the system at any point and make informed decisions. I see aggregates as part of the domain that reflects an organization's area of expertise. They can often be inferred from the domain events I track, making it easier for me to navigate complexity without getting bogged down by the traditional aggregate structure. This keeps my focus on the events and the insights they provide.

From my experience, most of the time this occurs because we are trying to model real world. Aggregates supports invariants and use cases and that is the main goal of them. If we try to model our domain as real life, we will start using ORM tools that will provide us options to code the relationships and associations but most of the time, these relationships might make sense in the real world, but can add unnecessary complexity when we implement code. The most important question we should ask ourselves as designers is: Are these entities within my Aggregate and their relationship support use cases and protect invariants? If the answer is NO, probably is an insight that you should add another Aggregate to protect consistency boundaries.

Domain events are good tactical options in cases we need to modify more than one aggregate and a good practice is we should not modify more than one aggregate per transaction. In cases where we need to do this because of the business rules and invariants, we can adopt and eventual consistency mechanism by using Domain Events. But we need to be careful and consider the tradeoffs this includes as managing distributed transactions.

Handling large, complex aggregates across multiple bounded contexts in a financial company, we start by mapping out the bank's products, then model processes via event storming, defining clear process boundaries. We establish bounded contexts, including communication, common language, and business rules. Identifying main aggregates and entities within these contexts ensures alignment with business needs. For large aggregates spanning contexts, we focus on seamless integration and consistent rule application, aiding effective microservice decomposition. This approach aligns with DDD principles, addressing large aggregate management efficiently.