This reminds me of this discussion and ideally it should be:
define core_app abstractions and core_app schemas (types) first
BUT changing the shape of persisted production data is an expensive effort which therefore runs into a lot of resistance, imposing a kind of technological inertia (Why Data Models Shouldn’t Drive Object Models (And Vice Versa) 2002).
Also the philosophy of:
is outmoded, which is why DDD puts domain types front and center, not database schemas. It’s the repository’s job to map the domain types to the DB schema and vice versa - serving as a special kind of anticorruption layer (ACL) to persistent storage. So ideally
- defining a schema of domain types and
- mapping those domain types to an existing storage schema
should be separate responsibilities. But for the sake of convenience of migrations those responsibilities are often conflated.
There’s at least 2
Personrepresentations
Even when it just comes to bounded contexts there could be two representations per context (Fowler) - separate from the database schema:
- one representation that the context (module) shares with the “outside” that is stripped of any implementation revealing details and
- another representation (with implementation revealing details) used between all the functions inside the context to get actual work done.
