You Cannot Judge Coupling and Cohesion From the Same View

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.

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.

.

: 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.