Architectural Principles

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.

Separation of Concerns means each part of a system deals with one distinct topic — for example, storing data, applying business rules, or drawing the screen — so you can understand or change one part without touching the others.

Crossing a boundary costs something: a function call is nearly free, a call to another process costs serialization, network latency and possible failure. Cheap boundaries can have fine-grained, chatty interfaces; expensive ones need coarse-grained calls that return everything needed at once.

CCP keeps code that changes together in one releasable unit, so a typical requirement change touches one component instead of many — one thing to build, test, version and deploy. It is the Single Responsibility Principle applied to components.

CRP says don't force users of a component to depend on things they don't need. Classes used together belong together; classes used separately belong apart. It is the Interface Segregation Principle applied to whole components.

Source dependencies point inward, toward policy: UI and database depend on use cases, use cases depend on the domain, and nothing inner knows anything outer. Because the inner circles define the interfaces, outer pieces plug into them and can be swapped like plugins.

DIP says high-level policy should not depend on low-level details — both should depend on an abstraction, and that abstraction should be owned by the policy side. In practice the business code declares the interface and the database or HTTP code implements it, so the dependency arrow points inward.

Strict layering lets a layer call only the layer immediately below it. Relaxed layering lets it call any lower layer, skipping levels. Strict gives better isolation and swappability; relaxed avoids pointless pass-through code but couples more layers together.

Cross-cutting concerns are needs like logging, security, or transactions that every part of the system uses, so they can't sit in one module. They're handled by pulling them into shared wrappers — middleware, interceptors, decorators — instead of copying the code everywhere.

No. A logical boundary says who may depend on whom; a deployable unit says what ships and runs separately. You can have strong logical boundaries inside one deployable process (a modular monolith) and only split into services when you need independent deployment, scaling, or isolation.

REP and CCP make components bigger; CRP makes them smaller, so you cannot satisfy all three. Ignore CRP and consumers get needless releases; ignore CCP and one change touches many components; ignore REP and the components are unusable by others.

LSP: any implementation of a type must be usable wherever that type is expected, without callers needing to know which one they got. ISP: don't force a client to depend on methods it doesn't use — prefer several small, role-specific interfaces over one fat one.

The domain declares interfaces describing what it needs ("save this order", "send this notification") in its own vocabulary. Infrastructure classes implement those interfaces, and something at startup wires the implementations in. Calls still go outward; the code dependency points inward.

Layering groups code by technical role — UI, business logic, data access — so each technology is isolated. Vertical slicing groups code by feature, so everything for "checkout" sits together. Layers optimize for swapping technology; slices optimize for changing one feature.

An anti-corruption layer is translation code at a boundary that converts another system's model, names and errors into your own. It stops a legacy or third-party design from leaking into and distorting your code, and localizes the damage when that system changes.

The Acyclic Dependencies Principle says the component dependency graph must have no cycles. Cycles make components impossible to build, test, or release separately. You break them either by inverting one edge with an interface, or by extracting the shared part into a new component both depend on.

Parnas says each module should hide one design decision that is likely to change — not represent one step of the processing flow. Encapsulation is the language mechanism (private fields, accessors) you might use; information hiding is the design decision about what to conceal and why.

Put boundaries where things change for different reasons and rarely change together. Group by business capability and by who owns the data, not by technical layer; check candidate lines against real change history and against how chatty the two sides would be.

REP means anything you want reused must be released as a versioned, documented unit with release notes, so consumers can tell what changed and choose when to upgrade. Its contents must form one coherent, explainable theme.

Source dependency = whose code names whose; build dependency = which artifact must be present to compile/link; runtime dependency = who calls whom and must be running. Over HTTP the caller still needs the callee at runtime, but you can invert the source/contract direction by having the consumer define the interface it needs and the provider satisfy it.

SDP: depend in the direction of stability — a component should only depend on components harder to change than itself. SAP: the more stable a component, the more abstract it should be. Instability I = outgoing/(incoming+outgoing) dependencies; abstractness A = abstract types / all types. Good components sit near the line A + I = 1.

Coupling, worst to best: content (reaching into another module's internals), common (shared global data), external, control (passing a flag that steers the callee's logic), stamp (passing a whole record when only a field is needed), data (passing just the needed values). Cohesion, worst to best: coincidental, logical, temporal, procedural, communicational, sequential, functional (one job).

Typical breakages: controllers containing business rules, database entities used directly as API responses, lower layers calling upward, skipping the domain to hit the database, and pass-through layers that add nothing. Each one couples layers that should change independently.

Instead of creating a module per business function, you create modules around the things most likely to change — a payment provider, a tax rule, a storage technology — and hide each behind a stable interface, so future changes stay inside one module.

Documents and good intentions don't hold. Enforce boundaries mechanically: language/module visibility so internals aren't importable, automated dependency-rule tests in CI that fail the build on violations, separate build modules, and — strongest and most costly — separate processes with separate databases.

A service is a releasable component, so the same rules hold: keep code that changes together in one service (CCP), avoid shared libraries that force everyone to redeploy (CRP), and version every published contract (REP). Justify changes with co-change and release data.