Mapping DDD domain models to EF POCO - entity-framework

Question

If there are two Customer domain models representing different bounded contexts (with different/overlapping fields), how are you supposed to Update this certain X bounded context Customer in the database that might be holding both those Customer domains in one POCO (or maybe Y bounded context Customer additionally uses a list of Orders of this same context)?
Also I could put it this way. How do you solve cases when domain models maps many to one with the database POCO?
Does it mean that repository would have to query db once more, but this time whole POCO object from DB, update its values accordingly and finally make the update?

Answer 1

It would help if you provided the 2 contexts and overlapping attributes of Customer. For the purpose of this answer Ill use the contexts: 'Sales' and 'Marketing' and the shared attribute is 'Preferred Name'
My initial thought based on the phrase 'overlapping fields' is that you need to revisit your model as you should not have 2 models responsible for a specific value otherwise you have concurrency/race conditions.
Try and think how your clients would resolve the situation in the old days of pen & paper. Who would own the 'customer' file? Would sales and marketing each have their own version, or would marketing rely on sales copy (or visa versa)?
Also, one of the most powerful aspects of DDD is it forces your persistence concerns way out into you infrastructure layers where they belong. You do not have to use EF for all your repository calls, if it easier to hand craft some sql for a specific persistence call then do it.
--Scenario 1: Overlapping field is not overlapping--
In this case, the domain experts came to realise that Sales.Customer.PreferredName and Marketing.Customer.PreferredName are independent attributes and can be different between contexts. Marketing often used the field for their cute we are you best pals campaign correspondence whilst Sales preferred to keep on file the most un-ambiguous
The CUSTOMER database table has 2 fields: PreferredNameSale and PreferredNameMarketing.
The 2 Concrete Repositories will end up looking something like:
class Sales.Repositories.ClientRepository : Domain.Sales.IClientRepository {
Update(Domain.Sales.Client salesClient) {
using (var db = new MyEfContext()) {
var dbClient = db.Client.Fetch(salesClient.Id);
dbClient.PreferredNameSales = salesClient.PreferredName;
db.SaveChanges();
}
}
}
class Marketing.Repositories.ClientRepository : Domain.Marketing.IClientRepository {
Update(Domain.Marketing.Client marketingClient) {
using (var db = new MyEfContext()) {
var dbClient = db.Client.Fetch(marketingClient.Id);
dbClient.PreferredNameMarketing = marketingClient.PreferredName;
db.SaveChanges();
}
}
}
Entity Framework should notice that only 1 field was changed and send the appropriate update client set field=newvalue where id=1 to the database.
There should be no concurrency issues when sales and marketing update their version of a single clients preferred name at the same time.
Also note that EF is providing a lot of overhead and very little value here. The same work could be completed with a simple parameterised SqlCommand.Execute()
--Scenario 2: Overlapping field is overlapping--
Your model is broken but it is too late to fix it properly. You lie to yourself that the chances of sales and marketing trying to change the preferred name at the same time is tiny and even if it happens, it should be rare that hopefully the user will blame themselves for not using the system correctly.
In this case, there is only one database field: client.PreferredName and as with scenario 1, the functions work on the same table/field:
class Sales.Repositories.ClientRepository : Domain.Sales.IClientRepository {
Update(Domain.Sales.Client salesClient) {
using (var db = new MyEfContext()) {
var dbClient = db.Client.Fetch(salesClient.Id);
dbClient.PreferredName = salesClient.PreferredName;
db.SaveChanges();
}
}
}
class Marketing.Repositories.ClientRepository : Domain.Marketing.IClientRepository {
Update(Domain.Marketing.Client marketingClient) {
using (var db = new MyEfContext()) {
var dbClient = db.Client.Fetch(marketingClient.Id);
dbClient.PreferredName = marketingClient.PreferredName;
db.SaveChanges();
}
}
}
The Obviously problem is that a save at the same time by both sales and marketing will end up with last one wins in terms of persisted data. You can try and mitigate this with lastupdated timestamps and so on but it will just get more messy and broken. Review your model and remember: DB MODEL != DOMAIN MODEL != UI View Model

Answer 2

Each bounded context is required to have its own database. That is it, there should be no discussion here. Violating this rule leads to severe consequences, which have been discussed many times.
Overlapping fields smell, different bounded contexts have different concerns and therefore do not require to have much data to share. The best case is when the only thing you share is the aggregate identity. If in your world you have one Customer that have different concerns handled by two different bounded contexts, you can use one CustomerId value for both bounded contexts.
If you really need to sync some data, you need to have it in both models, therefore in both persistent stores (I intentionally avoid the word database here) and you can sync the data using domain events. This is very common.