Definitions
- Cohesion: how strongly the things inside a module belong together. High is good. Things that change together should live together.
- Coupling: how much one module needs to know about another. Low is good. Changes shouldn't ripple.
- Separation of concerns: each part addresses one concern (UI, domain rules, persistence, transport).
diagram
Kinds of coupling (weakest → strongest)
- Message/event: you only know an event schema.
- Data: you pass plain values.
- Contract: you call a published API.
- Implementation: you know internal classes or tables.
- Shared database: the strongest and most dangerous; two services break each other's schema.
Also watch temporal coupling (A must be up for B to work) and deployment coupling (A and B must release together, which is a "distributed monolith").
Practical tests
- Can I change module X's internal schema without editing module Y?
- Does one feature request touch one module or five?
- Can a team own this module end to end?
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
Design PrinciplesApplied in production
SOLID Principles
Five object-oriented design principles that keep code open to change — single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
Foundation4 sources
Architecture PatternsUnderstood
Modular Monolith
One deployable unit, internally split into strongly bounded modules with explicit public APIs — microservice-style boundaries without the distributed-systems tax.
Intermediate4 sources
Architecture PatternsApplied in production
Microservices Architecture
Structure a system as independently deployable services, each owning a business capability and its data, communicating over the network.
Intermediate5 sources