DDD - object consistency in a limited context and various schemas in the database

Question

I am implementing DDD with Entity Framework Code First. My domain model is saved as it has no display layer.

I follow the approach suggested by Tech-Ed Julie Lerman. Each restricted context is mapped to a different schema within the same database.

If the same object says, the Client appears in different limited contexts, how do we maintain data consistency for the Customer object?

Answer 1

Only one limited context will be a recording system for your facility. If you cannot just leave with Id in other BCs, then you can include a subset of the object (usually not all properties) as an object of value.

Any changes to the object in the SOR must be published as one or more events in the messaging system that the descending BCs subscribe to in order to keep their data ultimately consistent.

Answer 2

In the example of Julie Lerman with Entity Framework (EF), she models a Contact in two different limited contexts - Sales Order (read-only) and Contact Management (being stable)). Since Eben proposes to keep these entities ultimately consistent, it can be achieved using the messaging system — in Julie’s example, she uses the ContactUpdatedEvent domain event, which the service can subscribe to forcing the model in another limited context, which will be re-read from source data (regardless of whether it is the database or the event itself containing the data in the DTO, for example), when this event is published - this will help ensure the final consistency data data.

Since your controller / presentation model / presenter / services must interact directly with the abstract interface for constant changes, that is, the repository template, and not the EF db context directly, in the example above, one Contact will come from one repository under one root aggregate, and another Contact will fall under a different root aggregate - therefore, two implementations of Contact objects will maintain the consistency of root aggregates in different ways, in which the Sales Order context will prevent Contact from being persistent.

Since you will represent Contact in two different limited contexts, they should not share the same behavior, so you should not worry about duplicating code other than property names for receiving / setting data, I am sure that this is something with which you can live. For example, the action “Request a contact to view your order” MAY be presented with behavior in the Contact class in the context of Contact Management , but MAY NOT have a value in the Contact class in the context of Sales Order .

EF does not force you to have associations between objects in both directions. The Fluent API mapping provides greater flexibility and allows you to have these associations one way.

If the idea of ​​your project is to follow DDD, I would advise you to completely forget about the database and EF, to start with and use the storage in memory to read and store your root aggregates. You can then focus on matching domain objects with your database using the EF Fluent API later, so that you won’t be forced to change your domain model to fit your database.