DDD - Multiple Bounded Contexts because of differing aggregate data?

We try to split up our domain into bounded contexts with the goal to have a modular application design/architecture.

We did an enlightening EventSorming session which helped us a lot to identify bounded contexts and its aggregates. After the workshop every participant agreed on the bounded contexts we identified.

Nevertheless we feel uncomfortable as we fear our bounded contexts are still too large. EventStomring focusses on the domain events / process and that's the major building block we used to identify our bounded contexts.

We also identified aggregates like "Contract". Every contract nearly follows the same process, but the amount of data these contracts contain can differ massively. There are very simple contract types and contract types which include a lot of additional data and attachments.

Is it meaningful to declare another bounded context just because the aggregate's data is more complex?

Both approaches have their drawbacks:

1. Implementing all contract types in one bounded context might lead to a lot of if-Statements in the code in order to handle the differing data.
2. Extracting a new bounded context might lead to a lot of duplicate code just because some data differs.

Any suggestions / best practices how to handle this?

...domain events / process and that's the major building block we used to identify our bounded contexts

BCs are not identified by processes, BCs are related to the language. Each BC has its own ubiquitous language (UL). A BC is the context in which a concept has meaning. Anyway BCs belong to the solution space. First of all you should explore the domain (problem space) and split it in subdomains, distilling the core domain. Then you model each subdomain. A BC is the context where a model lives. Ideally the relationship between subdomains and BCs is 1:1.

The process of discovering subdomains is iterative, and you will find them as you know the domain better, talking to experts. When you find a word that may have different meanings, or when two different words have the same meaning, then it means that you are crossing a boundary between BCs.

So, subdomains identification is not about processes, but about concepts and UL.

Is it meaningful to declare another bounded context just because the aggregate's data is more complex?

No, you shouldn't create BCs arbitrary just because aggregates are complex. BCs are based on the UL.

Any suggestions / best practices how to handle this?

You should learn more about the domain (contract, types, etc) by talking to domain experts, and study your aggregate (transactional consistency)... Anyway, if you split your aggregate into anothers, it doesn't mean that they belong to different BCs, they still can belong to the same BC. A BC can have more than one aggreagate. It all depends on your concrete domain.