Architecture is often presented as a choice between control and speed: define everything up front, or move quickly and accept the mess. A more useful framing is to ask how a system can learn. The architecture should make important qualities visible, keep changes local when possible, and give the team evidence when it is drifting away from its intent.
Design a direction, not a monument
Martin Fowler’s account of evolutionary architecture describes architecture as an ongoing effort that works closely with programming and feedback. The point is not that planning is unnecessary. The point is that a plan should be allowed to change when the product, constraints, or evidence changes. An architecture that cannot absorb learning becomes a tax on every new requirement.
This changes what “foundation” means. A foundation is not the most elaborate technology stack available. It is the smallest set of stable choices that protects the qualities the product actually needs: understandable boundaries, safe deployments, reliable data, acceptable latency, security, or the ability to replace a dependency later.
Keep boundaries explicit and proportionate
Boundaries are easier to reason about when they follow meaningful responsibilities: a domain, a workflow, an ownership relationship, or a change pattern. They should be visible in code, tests, and deployment paths — not only in a diagram. If two parts of the system change together every week, separating them into independently deployed services may add ceremony without adding independence.
That is why a modular monolith can be a strong starting point. It can establish clear module boundaries while keeping the operational model simple. Distribution becomes a deliberate response to a real constraint, such as independent scaling, isolation, or team autonomy. The architecture can then evolve one boundary at a time instead of turning the first release into a migration project.
- Give each module a clear responsibility and a small public interface.
- Make forbidden dependencies fail in automated checks, not only in code review.
- Separate a component when the benefit of independence is larger than the cost of operating it.
Write decisions down while they are still alive
An Architecture Decision Record (ADR) is a short document that captures a decision, its context, and its consequences. The format is deliberately lightweight. Its most valuable effect often happens before the document is finished: writing forces a team to name the problem, the alternatives, the trade-offs, and the conditions that would make the decision worth revisiting.
Keep ADRs close to the code they describe, give them a status, and link a superseded decision instead of rewriting history. Future teammates do not only need to know what the system does. They need to know what was considered reasonable at the time, and which assumption has since changed.
Turn architectural intent into feedback
A fitness function is an automated test that evaluates how closely an implementation matches a stated architectural objective. The objective might be that modules do not import one another directly, that an API stays within a latency budget, or that all production changes have an observable rollback path. The exact check matters less than making the quality concrete enough to inspect continuously.
Feedback is also why change size matters. DORA’s research identifies working in small batches as a capability that helps teams test hypotheses quickly and course-correct. Small changes are easier to understand, review, deploy, and recover from. They create a tighter connection between an architectural decision and the evidence that follows it.
RECHERCHEQUELLEN