Softwarearchitektur

Worum es geht

Software architecture is the set of design decisions that are expensive to reverse: where the system is cut, what each part is allowed to know, and how the pieces meet. Its founding insight is Parnas' — a module is defined by the decision it hides, so decomposition should follow expected change rather than the flow of processing — and its founding constraint is Conway's, that the design an organisation ships mirrors the way that organisation communicates. Everything else in the field is a consequence of those two facts meeting a third: complexity does not vanish, it moves. Coupling and cohesion name where it moved; quality-attribute trade-offs name what was paid for the move; technical debt names the interest charged when the structure and the team's understanding drift apart. The seams matter more than the parts, because a part can be rewritten in an afternoon and a seam is negotiated with every team, every schema and every deployment that depends on it.

Was im Paket steckt

Kuratiertes Gerüst, das dein Agent vor der Recherche lädt, damit er auf geprüftem Boden startet statt bei null.

• Tier 1: 18
• Tier 2: 7
• Tier 3: 18

Die Fragen und Behauptungen unten sind wörtlich aus den Paketdateien zitiert. Die Pakete sind durchgehend englisch, weil sie für Agenten geschrieben sind.

Wo das Feld sich uneinig ist

Jede trägt echte Vertreter auf mehr als einer Seite, damit dein Agent nicht still einen Sieger kürt.

• When, if ever, should a system be decomposed into independently deployed services?

  5 benannte Positionen · genuinely unresolved and probably not resolvable in general; the defensible position is that the choice is driven by organisational size, domain understanding and operational capability, and that neither side has controlled evidence

• Should structure be designed before the code, or discovered through it?

  4 benannte Positionen · the polarised version is dead in serious practice; the live question is which specific decisions are irreversible enough to deserve early attention, and that question is answered per system

• Is reorganising teams a reliable way to obtain a desired architecture?

  4 benannte Positionen · the correlation is established, the intervention is plausible and expensive, and its effectiveness has not been demonstrated by any design that could show causation

• Do the Accelerate findings show that delivery practices cause organisational performance, or that certain organisations answer surveys a certain way?

  5 benannte Positionen · the strongest empirical work the subject has, correctly cited as association rather than causation, and routinely over-cited as proof of causation and as a productivity score

• Does the debt metaphor clarify anything now that it means everything?

  4 benannte Positionen · contested in usage, not in origin; teaching it requires restoring Cunningham''s meaning first and naming the drift explicitly

Mythen, die das Paket korrigiert

Verbreitete Behauptungen mit der Evidenz, die sie klärt oder begrenzt.

• “Microservices scale better than monoliths.”

  debunked-as-stated

  The trade is organisational scaling for distributed-systems cost, and the sentence hides which scaling is meant. What decomposition genuinely buys is independent deployability — teams releasing without coordinating — plus independent resource scaling of specific hot components and smaller failure blast radius. What it costs is paid at every seam and never refunded: latency and serialisation on each hop, partial and ambiguous failure, consistency that used to be a transaction, operational surface, and boundaries that can no longer be moved by refactoring. Measured head to head on identical hardware, the microservice form of the same application delivered substantially lower throughput than the monolithic one, the loss attributed to communication and runtime overhead rather than to application logic. A monolith on one machine can be scaled horizontally too, by running more copies of it. The full cost list — consensus, retries and idempotency, timeout and backpressure design, clock and ordering problems, schema compatibility across independently deployed versions — belongs to the distributed-systems package, which is where a decision to add a network seam should be checked. Fowler's own observation is the practical form: the successful microservice systems he saw were split out of monoliths once their boundaries were understood, not designed distributed on day one.

• “Do not repeat yourself — if the same code appears twice, factor it out.”

  boundary-correction

  DRY as written concerns knowledge: each piece of knowledge should have one authoritative representation. Two fragments that look alike but encode different knowledge — a tax rule and a shipping rule that happen to multiply by the same number today — are not duplication, and merging them couples two things that will change independently, which is the precise failure Parnas' criterion warns against, since the criterion is about expected change and not about textual similarity. Metz describes the resulting decay pattern: callers with diverging needs add parameters and conditionals to the shared abstraction, each locally reasonable, until the abstraction is harder to understand than the duplication it replaced and sunk cost prevents removing it. Her rule — "duplication is far cheaper than the wrong abstraction" — is a statement about asymmetric cost, not a licence to copy-paste: wrong duplication is a local, findable problem, while a wrong abstraction is a coupling everyone inherits. The cost asymmetry sharpens at boundaries; a shared library spanning teams or services reintroduces exactly the coupling the boundary was drawn to remove, which is one of the mechanisms Segment reported when consolidating. Glass' survey of the reuse literature adds the price tag: building for reuse costs multiples of building for one use, so speculative abstraction is a real, quantified expenditure and not a free virtue.

• “There is one clean architecture, and a system either follows it or is wrong.”

  debunked

  Architecture selects among quality attributes that trade against one another: modifiability against performance, availability against consistency and cost, deployability against operational simplicity, security against usability. Because there is no ordering of those attributes independent of a specific system, organisation and constraint set, there is no architecture that dominates — which is why structured evaluation methods score architectures against stated scenarios rather than against a reference design, and why Richards and Ford state as their first rule that everything in architecture is a trade-off. Parnas himself supplied criteria for decomposition, not a canonical decomposition, and his 1972 paper is an argument about how to choose. The steelman of the clean-architecture position deserves stating, because the core claim is sound: keeping business policy free of dependencies on frameworks, delivery mechanisms and storage is information hiding applied to the most volatile decisions in a system, and it is widely accepted. What does not follow is that the ring diagram is the answer everywhere — the indirection, mapping layers and extra moving parts it costs are worth different amounts in a twelve-month startup product and a twenty-year clearing system.

• “Technical debt means bad code — the mess left behind by rushed or careless work.”

  debunked-as-stated

  Cunningham's 1992 metaphor was about the gap between the code and the team's current understanding of the problem. Shipping a first version built on partial understanding is like borrowing — often correct, because shipping is how the understanding is acquired — and interest is paid in the extra effort every subsequent change costs while the code still reflects the older, poorer model. Repayment is refactoring the code to match what the team now knows. Cunningham restated this in 2009 precisely because the metaphor had been reread as permission to write poor code deliberately, a reading he rejected: the borrowing is of understanding, not of quality. Fowler's quadrant makes the space explicit along deliberate versus inadvertent and prudent versus reckless, which locates careless work in one corner rather than at the centre; Kruchten, Nord and Ozkaya push further, separating visible defects from invisible structural debt and identifying architectural debt as the class that compounds, since it charges interest on every change and cannot be repaid by local tidying. Robert C. Martin's objection sharpens the point from the other side — calling careless work debt launders a decision nobody made into one that looks deliberate. The practical loss from the drift is real: when the word covers everything undesirable, it stops distinguishing the debt that is worth carrying from the debt that is compounding.

• “The architecture is beyond saving — a ground-up rewrite is the way to fix it.”

  debunked-as-stated

  Three things go wrong, and they are structural rather than incidental. First, the old system encodes requirements nobody wrote down: the accumulated corrections, edge cases and regulatory oddities that make the code ugly are the specification, and a rewrite starts without it — Spolsky's argument, written while Netscape's multi-year rewrite was under way and its market position eroded. Second, the second-system effect predicts that the replacement will be over-general, since the team now designs for everything the first system taught them plus everything they wished it had. Third, and most decisive for architecture: the causes of the structure — the communication structure, the incentives, the deadline pressure — remain in place, so Conway's law reproduces a comparable structure in the new codebase unless the organisation changed too. Meanwhile the rewrite competes for the same people who must keep the old system alive. The documented alternative is incremental: characterisation tests pin current behaviour, seams allow substitution without editing in place, and strangler-fig replacement moves capability edge by edge behind a facade while the system keeps running, with the option to stop at any point having banked partial value. Evidence quality stated honestly: this correction rests on expert argument and prominent case reports, not on controlled comparison, and rewrites do sometimes succeed — most defensibly when the target is a narrow, well-understood component, when the old platform is genuinely unsupportable, or when the organisational cause has itself been removed.

Verwandte Themen

• Verteilte Systeme
• Systemdenken