Entity configuration management with DDD bounded contexts

Question

I'm trying to implement multiple DDD bounded contexts as outlined here. This is an example context:

I have an entity type configuration file for each entity with the appropriate FluentAPI mappings (reverse engineered using EF tooling). These configuration files also include the relationship configurations.

e.g.: UserMap.cs

// Relationships
this.HasOptional(t => t.SecurityProfile)
    .WithMany(t => t.Users)
    .HasForeignKey(t => t.SecurityProfileCode);

SecurityProfile and DomainPermission are not DbSets in the context. They are automatically brought into the model due to the navigation properties on User and Module respectively.

This causes my first issue. When adding User (or any other entity) to any other context I have to remember to do one of two things:

1. Also add the configuration to the model builder for SecurityProfile (and every other relationship on the entity)

2. Exclude SecurityProfile from the model explicitly somehow.

This is starting to become a bit of a maintenance nightmare.

I would be satisfied to explicitly "trim" the entity graph as outlined in point 2 above.

However it doesn't seem possible to Ignore() entities when relationships are already being defined in the entity configuration files.

Trying modelBuilder.Ignore<SecurityProfile>(); for the above context OnModelCreating gives the following error in ConfigureAssociations():

System.InvalidOperationException: The navigation property 'SecurityProfile' is not a declared property on type 'User'. Verify that it has not been explicitly excluded from the model and that it is a valid navigation property.

The only solution I can think of is to inherit the base configuration classes and override the relationship configuration in each context. Considering we may end up with 30-40+ separate contexts this could also become a maintenance nightmare.

Alternatively I could have very specific entity models for each context, but again this would lead to entity class explosion and a potential maintenance problem in duplicated configuration.

How can I best manage and maintain entities and their entity configurations when implementing bounded contexts?

Answer 1

Added here due to a bit too long for comments:

It is extremely (un?)funny to note that the article you are referring to is apparently trying to jump on a bandwagon by mentioning a new buzzword DDD and subsequently showing only how DTO/POCO objects can be persisted in a context. This has absolutely nothing to do DDD.

Domain Driven Design is primarily about behavior and encapsulated (infrastructure isolated/ignorant) models that are iteratively explored and refined to solve specific problems for specific actors and that are expressed in the ubiquitous language of the problem domain.

These models typically do not map directly on some type of persistence model, nor should they be concerned with that. Operations performed on aggregate roots within a bounded context typically will align with transaction boundaries.

I would advise you to watch some of Eric Evan's webcasts on skillsmatter (keyword DDD eXchange) in order to get the right perspective on what DDD entails, what bounded contexts and aggregate roots are. And after that you also really should read his book, it's a great read. But you need his more recent perspectives (as expressed in these webcasts), not to fall in the trap of focusing on technology building blocks.