Clean Architecture — afhængighedsreglen

Clean Architecture — afhængighedsreglen

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs den venstre kolonne oppefra og ned som de fire lag, fra det inderste (entiteter) til det yderste (frameworks).
• Læs derefter den højre kolonne oppefra og ned som den regel, der styrer dem: afhængigheder indad, adaptere i midten, kernen urørt.
• Pilene går i ånden udefra og ind, selv om de er tegnet fra venstre mod højre — hvert ydre lags kode afhænger af laget inden for det.

De fire lag

»Entiteter — forretningsregler for hele virksomheden« er den inderste ring: objekter og regler, der findes, uanset hvordan appen leveres — en kunde, en faktura, reglen om, at en faktura ikke kan betales to gange. »Use cases — applikationsspecifikke regler« orkestrerer entiteter for ét scenarie i applikationen. »Grænsefladeadaptere — controllere, presenters« oversætter mellem use cases og omverdenen, og »Frameworks og drivere — UI, database, web« er den ydre ring af værktøjer.

Afhængighedsreglen

»Afhængigheder peger indad, aldrig udad« er den ene regel, hele arkitekturen findes for at håndhæve: afhængigheder i kildekoden krydser altid indad. »Ydre lag taler gennem adapteren, ikke til kernen« er mekanismen — et use case erklærer et interface til at gemme en faktura, og databaseadapteren implementerer det, så use casen aldrig importerer databasebiblioteket.

Gevinsten

»Skift framework uden at røre kernen« og »Kernen importerer aldrig et framework« er prøven på, om reglen blev holdt: migrér fra én database eller ét UI til et andet, og entiteter og use cases ændrer sig slet ikke. Det er hele værditilbuddet — den vigtigste og dyreste kode er isoleret fra den mest udskiftelige.

Key relationships and takeaways

• Afhængigheder peger altid indad — den ene regel er, hvad arkitekturen er.
• Kernen erklærer interfaces; de ydre ringe implementerer dem — adapteren er sømmen.
• Entiteter og use cases er frameworkuafhængige af konstruktion.
• Gevinsten er udskiftelighed: skift UI, database eller webframework uden at røre kernen.
• Clean Architecture handler om afhængighedernes retning, ikke om antallet af lag.

When to use this visual

• At lære et team afhængighedsreglen, før de strukturerer en stor kodebase.
• At gennemgå en arkitektur: et use case, der importerer et UI- eller databasebibliotek, er et brud på reglen, og det er synligt på lærredet.
• At planlægge en omskrivning eller migrering — lærredet viser, hvilke lag der skal overleve, og hvilke der kan skiftes ud.

Sådan fungerer det

1. Omdøb lagene til jeres egen stack

   Erstat de generiske ringnavne med jeres egne — jeres entiteter, jeres use case-klasser, jeres controllere og gateways, jeres faktiske frameworks til UI og database.

2. Tegn sømmene ved grænsefladerne

   Tilføj de interfaces, kernen erklærer, og hvilken adapter der implementerer hvert af dem, så diagrammet dokumenterer de sømme, afhængighedsreglen krydser.

3. Markér bruddene

   Giv ethvert lag, der i dag importerer udad, en etiket eller en anden figur, med en note om den refaktorering, der ville rette det — lærredet fungerer samtidig som en gennemgang.

4. Vis en reel udskiftning

   Tilføj en gren, hvor ét ydre framework erstattes af et andet, og hvor begge forbinder gennem den samme adapter og ender i den uændrede kerne.

Ofte stillede spørgsmål

Hvad er Clean Architecture?

Det er et arkitekturmønster, gjort udbredt af Robert C. Martin, som organiserer kode i koncentriske lag: entiteter i midten, derefter use cases, derefter grænsefladeadaptere og yderst frameworks og drivere. Den styrende regel er, at afhængigheder i kildekoden altid peger indad, så de centrale forretningsregler aldrig afhænger af leveringsmekanismerne — UI, database eller webframework.

Hvad er afhængighedsreglen?

Afhængighedsreglen siger, at afhængigheder i kildekoden altid skal krydse indad: et ydre lag må afhænge af et indre lag, aldrig omvendt. I praksis erklærer de indre lag interfaces, og de ydre lag implementerer dem, så kernens kode ikke importerer noget fra værktøjerne i kanten. Diagrammet tegner det som sin egen gruppe, fordi hver eneste anden egenskab ved arkitekturen følger af den.

Hvordan adskiller Clean Architecture sig fra lagdelt arkitektur?

Lagdelt arkitektur adskiller også ansvar, men dens afhængigheder løber som regel oppefra og ned — præsentationslaget kalder servicelaget, som kalder datalaget. Clean Architecture vender det om: forretningskernen ligger i midten, og alt andet afhænger af den, så afhængighedernes retning er det, der adskiller dem. Diagrammets pil ind mod kernen er forskellen gjort synlig.

Er Clean Architecture besværet værd i et lille projekt?

Ikke altid — ceremonien koster mere, end den giver, når forretningsreglerne er trivielle, eller teamet er én person. Mønsteret tjener sig ind, når forretningslogikken er kompleks nok til, at den skal overleve værktøjerne, eller når UI'et eller databasen sandsynligvis vil ændre sig. Gevinstboksene på lærredet siger byttehandlen ærligt: kernens sikkerhed er købt med adapterlagene.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis dette Clean Architecture-lærred som dit eget diagram, omdøb lagene til jeres egen kodebase, og tegn jeres afhængigheder.

Redigér dette diagram i QueryChart (FlowJam)