The contexts stand, and so do the relationships. In the Kladde's database you can't see any of that yet: one KladdeDbContext knows all the tables, all of them live in the same schema, and every page may read every table. As long as that stays so, the boundaries from lesson 4.2.4 are only paper. An appointments page that reads the contacts table breaks as soon as the contacts change their model, and nobody notices before the next bug. In this lesson you settle which table belongs to whom, find the places where a context reads foreign tables and design a path for each that respects the boundary.

What ownership means

Every context owns its data. That means three things:

  1. Only the owner writes. No other context changes a row in a foreign table, not even “just this one field”.
  2. The owner determines form and meaning. It may rename a column, split it or fill it differently without asking anyone, as long as its contracts stay the same.
  3. Others never read the table, not even read-only. Whoever reads a foreign table depends on its form and its meaning. If the owner splits Name into first and last name, the reader is broken although it never wrote anything.

A table that two contexts use together is therefore no shortcut but a hidden coupling: both have to coordinate on every change, and nobody knows exactly whose rules apply to the data.