How does that make sense?
Short answer: it doesn't.
Longer answer: the heavyweight patterns for developing a domain model don't apply to those portions of your solution that are just a database.
Udi Dahan had an interesting observation that may help clarify this
Dahan considers that a service has to have both some sort of functionality and some data. If it does not have data, then it is just a function. If all that it does is performing CRUD operations on data, then it is database.
The point of the domain model, after all, is to ensure that all of the updates to the data maintain the current business invariant. Or, to put it another way, the domain model is responsible for ensuring that the database that acts as the system of record is correct.
When you are dealing with a CRUD system, you usually aren't the system of record for the data. The real world is the book of record, and your database is just a locally cached representation of the real world.
For instance, most information that appears in a user profile, like an email address, or a government issued identification number, has a source of truth that lives outside of your business -- it's somebody else's mail administrator that assigns and revokes email addresses, not your app. It's the government that assigns SSNs, not your app.
So you aren't normally going to be doing any domain validation on the data coming to you from the outside world; you might have checks in place to ensure that the data is well formed and properly sanitized; but its not your data - your domain model doesn't get a veto.
In a DDD approach using layers, it seems like CRUD operations go through the domain layer. but at least in our case, this doesn't seem to make sense.
That's right for the case where the database is the book of record.
Ouarzy put it this way.
Working on lots of legacy code though, I observe common mistakes to identify what is inside the domain, and what is outside.
An application can be considered CRUD only if there is no business logic around the data model. Even in this (rare) case, your data model is not your domain model. It just means that, as no business logics is involved, we don’t need any abstraction to manage it, and thus we have no domain model.
We use the domain model to manage the data that belongs inside the domain; the data from outside the domain is already managed somewhere else -- we're just caching a copy.
Greg Young uses warehouse systems as a primary illustration of solutions where the book of record is somewhere else (ie: the warehouse floor). The implementation he describes is a lot like yours -- one logical database to capture messages received from the warehouse, and then a separate logical database caching the conclusions drawn from the analysis of those messages.
So maybe we have two bounded contexts here? Each with a different model for an
Maybe. I'd be reluctant to tag it as a bounded context, because it's not clear what other baggage comes along with it. It might be that you have two contexts, it might be one context with subtle differences in the ubiquitous language that you haven't picked up yet.
Possible litmus test: how many domain experts do you need; two domain experts to cover this spectrum, or just one who talks about the components in different ways? Basically, you might be able to guess how many bounded contexts you have by working Conway's law backwards.
If you consider bounded contexts to be aligned with services, it may be easier: should you be able to deploy these two pieces of functionality independently? Yes suggests two bounded contexts; but if they need to be kept synchronized, then maybe its just one.