Every engineer can recite the goal: low coupling, high cohesion. Fewer dependencies between modules, more relatedness inside each one. We say it so often that it sounds like one rule. It is two, and they live at two different scopes.

Coupling is a property of the boundaries. It is about what crosses between modules. Cohesion is a property of the interior. It is about whether the things inside a module belong together. A diagram that is good at showing one is usually bad at showing the other, because the scope you need to see is different. To judge coupling you zoom out until the boundaries are visible. To judge cohesion you zoom in until a single module fills the frame and nothing else competes for attention.

This is why I gave Schemity two kinds of view, and why I keep using my own auth schema as the example.

The main view is for reasoning about coupling

The main view shows every context at once: auth, account, audit, localization. You are not meant to read individual columns here. You are meant to read the edges that cross context borders.

Look at where lines leave the auth box. roles.tenant_id reaches into account. sso_configs.tenant_id does the same. member_roles.member_id points at members. otps carries both tenant_id and member_id. That bundle of crossing edges is the entire coupling surface between authentication and the account model. It is small, and it is all of the same shape: a tenant or a member identity flowing inward. That is what loose coupling looks like in practice. Not zero dependencies, but few dependencies, all pointing the same way, all explainable in one sentence.

If that surface were wide and tangled, no amount of clean code inside the contexts would save the design. You would feel it as the change that always spreads. The main view is where you catch that early, before it is written into a hundred files.

The small markers on frontier tables are doing exactly this job. They flag the tables that participate in a cross-context relationship, so the coupling surface is a thing you can point at rather than a thing you discover during a migration.

The context view is for reasoning about cohesion

Once you trust the boundaries, the question changes. Now you want to know whether each context is actually one thing, or three things sharing a folder. For that, the rest of the world is noise. So the context view drops it.

And dropping it does more than declutter. In the main view, the layout is mostly busy answering coupling - every table has to coexist with every other context and every crossing edge, so its position is decided by global constraints, not local meaning. The context view lifts that constraint. You can arrange the tables freely, by how they relate to each other rather than how they fit into everyone else’s picture. The canvas space and the attention that the main view spent on coupling are now available for cohesion. That is the real reason the clusters surface - you finally have room to put related things next to each other.

Here is auth alone. Read it as a claim: these tables change for the same reasons. They mostly do. There is SSO and identity-provider configuration (sso_configs, claim_mappings, group_role_mappings). There is authorization (roles, member_roles, roles_pems, pems). There is one-time verification (otps). Three clusters, but one subject: how a request is authenticated and what it is allowed to do. The cohesion is real because every table answers a question the security layer has to answer.

The same lens applied to account separates two concepts that beginners almost always collapse.

users is a person: an email, a name, an identity that exists once. members is that person’s existence inside a tenant: status, language, tokens, the tenant they belong to. One human is one users row and potentially many members rows. Keeping them apart is a cohesion decision. A users table that also held tenant-scoped status would be answering two questions, and would change whenever either answer changed. The split is also a naming decision, and the two are connected. When the names are right (user for the person, member for the membership), the cohesion is usually right too, because confused names are how unrelated responsibilities sneak into the same table.

Why the views have to be separate

You could try to show both at once. People do, and the result is the diagram nobody opens: every table, every line, no grouping, the coupling invisible inside the density and the cohesion invisible because nothing is isolated. The information is technically present and practically unreadable.

The honest move is to accept that the two principles are answered at two scales and build a view for each. The main view answers are the boundaries clean. The context view answers is each interior coherent. A design is healthy only when both answers are yes, and you cannot get both answers from one picture.

So the next time you are about to evaluate a schema, or a service map, or a module graph, ask which question you are actually asking. If it is about dependencies, zoom out until you see the borders and count what crosses them. If it is about responsibility, zoom in until one module is alone and ask whether it has one reason to change. Two questions, two scopes, two views. Trying to answer both at once is how good designs get judged badly.