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:

Sample 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:

Also add the configuration to the model builder for SecurityProfile (and every other relationship on the entity)
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?

Odd that someone would vote to close this considering the EF Project Site states "For questions about using Entity Framework in your application please post a question on Stack Overflow using the entity-framework tag." — Brett Postin
If you look at the close vote you'll see that it was "Too broad". And I agree wit that. You have three questions and not one. A side note: DDD says that your entities should be persistance ignorant which your entites are not, since you obviously have to change them so that they fit the requirements of EF. — jgauffin
@jgauffin I'd be happy to condense the 3 questions down to the 3rd one. However this isn't a simple "how do I do this" question and the background information is helpful to all 3 questions. So the reason of it being "too broad" isn't valid imo considering SO is the recommended outlet to ask these types of questions. Maybe this is a problem with open source projects hijacking SO as their community channel. But seemingly without any other options, this is the only outlet I'm hopeful of getting a response. — Brett Postin
@HonorableChow I agree and I'm coming to the same conclusion. This article along with this thread are quite helpful. I think the best solution is to keep everything in the context specific to that context. I'm starting to come to terms with the fact that tailored class explosion is an unavoidable consequence of this architecture. — Brett Postin
@BrettPostin I wouldn't see it as a EF specific problem. Your bounded context shouldn't leak into other bounded contexts, otherwise it's not bounded anymore. True aggregate design only stores the keys of elements that are outside the aggregate. The same is true for bounded context. I don't know if you already read Vaughn Vernons book (amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/…) but it helped me a lot in understanding bounded contexts — Wouter de Kort

Alex Alex · Accepted Answer · 2013-09-02T02:25:10

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.

Entity configuration management with DDD bounded contexts

1 Answers