Design, structure and tradeoffs

you changed one module and three tests in a directory you had never opened went red.

Coupling

the code for one job is spread over four files, and each of those files also does three unrelated jobs.

Cohesion

the call only works if you remember to call the other method first, and nothing tells you that.

Temporal coupling

you wanted to change the retry policy and had to read a HTML template to find where it was set.

Separation of concerns

two teams keep editing the same class for two entirely unrelated reasons and keep colliding.

Single responsibility

another team reached into the field directly, and now you cannot rename it without breaking them.

Encapsulation

you wrote order.getCustomer().getAddress().getPostcode() and a change three objects away broke your line.

Law of Demeter

you called something that looked like a getter and it wrote a row to the database.

Command-query separation

the method called save() also sent an email, and somebody found that out in production.

Principle of least astonishment

nobody used the option because nothing about the API suggested it was there.

Affordance

the ORM hid the SQL right up until you had to read the query plan to fix a timeout.

Leaky abstraction

the function reads like a sentence for three lines and then drops into byte offsets.

Level of abstraction

you followed the call through four interfaces to find the one line that actually does the work.

Indirection

the controller called the database directly and three people commented on the pull request.

Layered architecture

the business rules import the Postgres driver, so testing a discount calculation needs a database.

Dependency inversion

you needed to test the payment path and there was nowhere to slip a fake in without editing the code you were testing.

Seam

you swapped the storage backend and did not have to open a single pricing rule.

Orthogonality

the new feature was two things you already had, wired together, and nothing new was written.

Composability

the subclass needed one method overridden and inherited four others it never wanted and cannot remove.

Composition over inheritance

'customer' means one thing to billing and something else to support, and the shared table forces one of them to be wrong.

Bounded context

the code says Account, the spec says Subscription, and in standup everyone says plan.

Ubiquitous language

everything ships together, so one bad line in someone else's feature blocks your release.

Monolith

you kept the single deployable and made a module boundary something the build fails on when crossed.

Modular monolith

the service you own deploys on its own schedule and you have never waited for another team's release.

Microservice

you split it into six services and still have to deploy all six together, in the right order.

Distributed monolith