Architectural Principles
The same design instincts applied at system scale: where boundaries go, which way dependencies point, how to layer, and what belongs in one component. These are the principles you cite when justifying a module structure to a room of architects.
part ofSoftware design & architectureoverview, primer and where to startread it →on this pageshowhide
explore
- Separation of Concerns5 questions
- Architectural Boundaries6 questions
- Dependency Direction6 questions
- Layering5 questions
- Component Cohesion Principles6 questions
- Design Principles (Code Scale)6 questions
questions
page 2 of 2When does horizontal technical layering (presentation/domain/infrastructure) become a liability, and what structural alternatives — such as vertical feature slices or modular decomposition — would you choose instead?
basics
~20 sLayering groups code by technical role, so one feature is spread across many folders and most changes touch every layer. When features change independently and teams own features, grouping by feature (vertical slices or modules) — with layering applied inside each slice — usually beats a single global layer stack.
How do you decide when NOT to separate two concerns? Give the costs of a boundary and the signals that a split is wrong.
basics
~20 sEvery boundary costs something: extra interfaces, mapping code, and — if it's a process boundary — network calls and lost transactions. Don't split when two things always change together, must stay consistent in one transaction, or when you don't yet understand the domain.
Dependency inversion has real costs. As the architect of a large system, how do you decide which dependencies to invert, and how do you keep the chosen dependency direction from eroding over time?
basics
~20 sInvert only where volatility crosses an important boundary — vendors, I/O, the clock, anything you might replace. Skip it for stable, single-implementation code. Then make direction machine-enforced: separate build artifacts and architecture tests in CI, not code-review discipline.
Meilir Page-Jones proposed "connascence" as a finer-grained replacement for the coupling/cohesion vocabulary. What is it, what are its three measures, and how does it guide refactoring decisions across a module boundary?
basics
~20 sConnascence means two pieces of code are "born together": if one changes, the other must change to stay correct. It names the kind of agreement (name, type, position, meaning, algorithm, timing, order, identity) and rates it by strength, degree, and locality — giving concrete refactoring targets instead of a vague "too coupled".
showing 31–34 of 34