In most domains, there is an app that "prepares" data, and another app that "serves" the prepared data. The data, however, is from the same Core Domain, which causes some confusion in modeling.
- In a shipping/cargo app, there will be one UI for management: staff members will add/update/delete cargos, voyages, and customers. Then in another UI or part of the application, someone will leverage this prepared data to do the heavy lifting of matching cargos to voyages, depending on requests from customers, perhaps exposing it as an API.
- In an advertising application, there will be a UI where staff or advertisers can add/update/delete ads, which will include bids, restrictions (geo, devices, etc). Another app will take this information and use it to "serve" the prepared data.
There are tons of other examples but they share the same pattern: preparation of data, and serving the same data. Both of these share the same information, such as ad restrictions and payouts in the advertising domain, but use them in different contexts. "Preparing" can commonly be CRUD-based, whereas "serving" more involved.
How does one model these? Should there be a single bounded context related to core domain where the same entities are used? Or are they to be considered entirely separate contexts, where a shared kernel may include entity IDs, and perhaps a shared underlying database?
I have been looking into the CQRS pattern which might be helpful. To use the advertising domain, "preparing" the data could use both commands and queries (sort of a CRUD pattern), while the "serving" could use dedicated queries (which would obviously be very different.)
Still, I cannot shake the feeling that separating these entirely would create a lot of duplication, plus high coupling, e.g. if a new restriction is added on an ad (perhaps "operating system name") then it would simultaneously need to be added to the "preparation" and "usage" stages.