Cohesion

Cohesion asks whether elements inside a module belong together — they change for the same reason, share invariants, or need one owner to preserve behavior. High cohesion keeps related logic local; low cohesion spreads one concept across layers and services.

In microservices and modular monoliths alike, weak cohesion shows up as scattered validation, duplicated business rules, and "god services" that own unrelated workflows. Strong cohesion often aligns with bounded contexts but still requires discipline inside each service.

On interviews: critique a decomposition by cohesion, not folder names. Explain when splitting a module improves clarity versus when it only adds network hops.

Common pitfalls: splitting by CRUD tables instead of business capabilities; extracting a microservice before the domain model is understood; low cohesion masked by a shared utility package.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• State the single reason the module changes together.
• Check for duplicated invariants across services.
• Prefer colocating rules with the data they protect.
• Re-merge modules that always change in lockstep.