Software design & architecture

Cohesion is how strongly the things inside one module belong together. Coupling is how much one module depends on another. The rule: aim for high cohesion inside modules and low coupling between them.

Inheritance reuses code by making a new type a subtype of an existing one ("is-a"). Composition reuses code by holding another object as a field and calling it ("has-a"). Prefer composition: it couples types less and can change at runtime.

Abstraction hides detail behind a simpler idea you can reason about, like 'send a payment'. Indirection just means going through something in between instead of calling the thing directly. Abstractions use indirection, but a pass-through wrapper that hides nothing is only indirection.

CQS says every method should either change state (a command, returning nothing) or return information (a query, changing nothing) — never both. Put differently: asking a question must not change the answer.

Fail fast means checking for invalid input or state right where it appears and stopping immediately with a clear error, instead of continuing with bad data that causes a confusing failure much later somewhere else.

An object hides its data and exposes behaviour - you tell it to do something. A data structure exposes its data and has almost no behaviour - other code reads its fields and does the work.

Always leave code a little better than you found it. Whenever you touch a file, make one small safe improvement — a clearer name, a deleted unused line, an extracted helper — so quality slowly rises instead of decaying.

Cyclomatic complexity counts the independent execution paths through code, which estimates how many tests you need. Cognitive complexity estimates how hard code is for a human to read: it penalises nesting and ignores structures people find easy.

A guard clause handles an invalid or special case immediately and returns, instead of wrapping the real work in an if. That flattens nesting, so the reader stops carrying conditions in their head and the main path stays at the left margin.

The code already shows what it does; a reader can see that. It cannot show the reason, constraint, or bug that forced this approach. "Why" comments add information; "what" comments repeat it and can go stale.

Abstract Factory gives you one interface with several creation methods that together produce a set of related objects. Client code asks the interface for parts and never names concrete classes, so swapping one factory swaps the whole matching set.

Adapter converts one type's interface into the interface a caller already expects, so two otherwise incompatible pieces of code can work together. The adapter wraps the existing type and translates each call, without changing either side.

A god object is one class that knows and does almost everything: data, rules, coordination, I/O. Because everything depends on it and every feature edits it, it is hard to understand, hard to test, and a constant source of conflicts and bugs.

Behavioral patterns describe how objects talk to each other and who is responsible for what. Creational patterns are about how objects get made; structural patterns are about how objects are composed into bigger shapes.

Bridge splits a design into two separate hierarchies — an abstraction (what the thing is) and an implementation (how it does its work) — connected by a reference instead of inheritance, so each side can grow independently.

A boundary is a line separating parts of a system that change for different reasons. The interface is the small set of operations other parts may call; the implementation is the hidden internals (data structures, algorithms, storage) they must not touch.

REP: things released together should be usable together. CCP: put classes that change for the same reason in the same component. CRP: don't force users to depend on code they never use. Together they decide component contents.

DIP says high-level policy should not depend on low-level details; both should depend on an abstraction. You define an interface next to the policy, the policy calls it, and the detail implements it — so the arrow now points from the detail to the policy.

Coupling is how much one module depends on another; cohesion is how well the things inside one module belong together. Low coupling means changing one module rarely forces changes elsewhere; high cohesion means each module does one clear job.

Presentation handles input and output (UI, HTTP endpoints). Domain holds business rules and decisions. Infrastructure talks to databases, files, and other systems. Dependencies point one way — upper layers know about lower ones, never the reverse.

Inner circles (business rules) must never depend on outer circles (frameworks/DB). The use case defines an interface it needs; a database-specific class outside implements it. This keeps business logic free of database code.

A port is an interface the core app defines. Driving ports are ways the outside world calls INTO the app (like an API). Driven ports are ways the app calls OUT to things it needs (like a database).

The core is a small always-on engine that only knows how to load and talk to plug-ins. Plug-ins are separate, swappable pieces of code that add actual features, each following rules the core sets.

Model holds data and business rules, View shows it on screen, Controller takes user input and decides what happens next. Splitting them means you can change how something looks without touching how it works.

Onion Architecture puts the business rules in the middle of the app, like the core of an onion, and everything else (database, web framework, UI) sits in layers wrapped around it. The middle never needs to know about the outer layers.

When two halves of a system can't talk to each other, you must pick: either every request works but might return old/wrong data (available), or requests wait/fail until the data is provably correct (consistent). You can't have perfect answers and instant answers at once during that outage.

Computer clocks aren't perfectly synced - they drift apart between corrections and can even jump backward during a correction, so timestamps from two different machines can't be trusted to show which event really happened first.

A majority is needed so any two quorums always share at least one node - that overlap is what stops two different decisions from being made at once.

2PC asks everyone 'can you commit?' first (prepare phase). Only if all say yes does it tell them to actually commit (commit phase). If anyone says no, everyone rolls back.

A short timeout catches crashes fast but often wrongly declares a slow-but-alive node dead. A long timeout avoids false alarms but takes longer to notice a real crash.

It's an anti-corruption layer - a translator sitting at the boundary that converts a foreign or messy system's data/language into your own clean model, so ugliness on the other side never leaks into your code.

It's a single door that all client requests pass through before reaching the actual services behind it. Instead of a client knowing about and calling ten different services, it talks to one address, and the gateway figures out where to send each request.

A BFF is a small backend built just for one type of app (like a mobile app or a website) so that app gets exactly the data it needs in one call, instead of talking to lots of different services itself and stitching the results together.

A synchronous call waits for an immediate answer before moving on, like a phone call. An asynchronous message is sent off while the sender keeps working, like leaving a voicemail; the other side handles it and replies whenever it's ready.

Because the same built package has to run in different places (laptop, test, live servers) that need different settings. If settings are baked into the code, you'd have to rebuild the whole app just to change a URL, and test settings could leak into production.

A command asks the system to do something and can be refused, like a request. An event says something already happened and is a fact - you can't refuse a fact, only react to it.

The read copy of the data updates a little after the write copy, through a background sync step. Until that catches up, queries can show old data. That gap in time is called the lag window (or replication lag).

CQRS just means writes and reads use different models. Event Sourcing means you store every change as an event instead of overwriting data. You can do CQRS without Event Sourcing, but when a team does use Event Sourcing, the event log naturally becomes the write side and the read side is built from those events.

A projection is a read-only copy of your data, shaped for easy querying, that's kept updated by watching events from the part of the system that handles writes. Teams build it because the write data is often shaped for correctness, not for fast, flexible reading.

A read model is a copy of your data shaped exactly for what a screen or report needs to show, separate from the data structure used to save changes. It exists so reading is fast and simple, and writing stays focused on correctness.

An aggregate root is the single object outside code may touch inside a related cluster. Everything else is reached through it. Other code keeps just its ID, not a direct pointer, so it can't reach in and break the rules.

An application service coordinates a use case — starts transactions, checks permissions, calls objects, converts data — without deciding business rules. A domain service holds business rules that don't fit one entity, like a rule spanning two accounts.

A bounded context is a boundary around a part of a system where a specific model and its terms have one exact meaning. Outside that boundary, the same word can mean something completely different.

A context map is a diagram showing all the bounded contexts in a system, how they connect, which one leads (upstream) vs follows (downstream), and which teams own each one.

An Anti-Corruption Layer is a translation wall between your code and someone else's system, so their messy or different data model doesn't leak into and pollute your own model.

An Anti-Corruption Layer is a translator between two systems. It converts the old system's weird data and terms into clean data your new system understands, so the mess doesn't spread into your new code.

The server says 'got it, working on it' right away instead of making the client wait. It hands back a link the client can check later to see if the work is done. This keeps the connection short and frees the client to do other things while it waits.

Bulkhead means giving each external service its own separate pool of workers/connections, like separate lifeboats on a ship. If one dependency gets slow or breaks, it only uses up its own pool — it can't eat all the workers other dependencies need.

The app checks the cache first. If the value isn't there (a miss), the app reads it from the real database, saves a copy in the cache, then returns it to the caller. Next time it's a fast cache hit.

A circuit breaker watches calls to another service. Normally it's 'closed' and lets calls through. If too many fail, it 'opens' and stops calling that service for a while, failing fast instead. After a timeout it lets a few test calls through ('half-open') to check if the service recovered.

APM is keeping a living list of every application a company runs — what it does, who owns it, what it costs, and how risky it is — so leaders can decide what to keep, fix, or retire.

Business layer = what the company does for customers (processes, services). Application layer = the software that supports those processes. Technology layer = the infrastructure (servers, networks) that runs the software. Higher layers use services from the layer below.

Enterprise architects use Porter's value chain to map out every business activity, from making the product to selling it, and check which IT systems support the activities that make money versus the ones that just keep things running.

A capability is 'what' a business can do (e.g., 'Manage Customer Orders') - stable and abstract. A process is 'how' it's done, step by step, and changes more often.

BDAT = Business, Data, Application, Technology. Business is how the company works (processes, org). Data is what information exists and what it means. Application is the software that manages it. Technology is the hardware/infrastructure it all runs on.

It's called a 'diamond dependency conflict.' Two things your app needs each secretly need a different version of the same third thing, but most systems can only load one version of a library at once, so something has to give.

A lockfile records the exact version of every package (including indirect ones) that got installed, so everyone who installs later gets the identical set of files instead of whatever the version ranges happen to resolve to that day.

SemVer is MAJOR.MINOR.PATCH. 2.3.5→2.4.0 (MINOR) means new features were added, safe to upgrade. 2.4.0→3.0.0 (MAJOR) means something incompatible changed - your code might break, so check the changelog first.

An attacker publishes a public package with the exact same name as a company's private internal package. If a build tool checks the public registry and grabs whichever version looks newest/highest, it installs the attacker's fake package instead of the real internal one — no phishing or malware download needed, just a naming collision.

A direct dependency is a library you add yourself. A transitive dependency is a library that gets pulled in automatically because one of your direct dependencies needs it to work.