Aggregates, Transactional Consistency and the Entity Framework DbContext

Question

Aggregates must be designed to be transactionally and eventually consistency. This consistency boundary around entities helps manage complexity.

In our repository implementations, we are using Entity Framework to interface with the actual database. Historically we have always had huge contexts (spanning scores of tables) which represent every available table, field and relationship in the database (or at least in some functional area of the database). The problem here is that this context is used for hundreds of different things and grows exponentially as the system gets bigger, leading to something which is very difficult to maintain.

Division by Bounded Context

Due to this, it is often suggested that separate DbContexts should be created for each bounded context in the system. Julie Lerman proposed this in her article, Shrink EF Models with DDD Bounded Contexts.

Division by Aggregate

If our aggregates are transactionally consistent, what is stopping us from going one step further and creating dedicated contexts to serve each aggregate repository?

Instead of being promiscuous (serving everyones' needs), it would give the context clear intention.

• The context will only ever need to change when the aggregate needs to change. It evolves with the aggregate. With larger contexts, many parts of the system could depend on one part of the context. A single change could jeopardise a lot.

• Only the tables, fields and relationships needed by the aggregate will need to exist in the context. Often when dealing with a larger context, you aren't bothered with most of the relations or fields on a given table.

There are drawbacks with this approach. Namely:

• Although they would likely be modeled differently (depending on their use), certain database tables and relationships may need to exist in multiple contexts.

• If used, code-first migrations would be tricky.

• This may be considered as over-engineering.

Can anyone provide further any insight on this approach? Is there perhaps something which I have overlooked?

EDIT:

Note that we are not using the EF data entities in our domain. Our repositories instantiate and hydrate from these data entities a richer domain model.

Answer 1

I don't see multiple-aggregate Contexts as a problem, especially if you follow strict aggregate separation -- no reference to entities outside aggregate, only root-to-root loose references by key.

On the other hand, I could see why you would want atomic DbContexts if you know for sure it's a performance bottleneck.

One thing though : EF contexts don't have to map exactly to Domain layer Bounded Contexts. If they do and you try to shrink your contexts as much as possible on both sides, it could cause damage in the Domain layer IMO. The domain BC's could lose their coherence and the semantics of important ubiquitous language notions and subdivisions could be lost in the process.