Clean Architecture
Clean Architecture et arkirekture mønster og en bok skrevet av Uncle Bob
Hovedideen er at arkitekturen ikke skal være avhengig av dets rammeverk, UI, database etc. Avhengigheten skal inverteres slik at disse er avhengig av kjerne, business regler. Business reglene skal altså ikke bry seg med hvordan man skal lagre informasjon, eller hvordan man presenterer det. De skal bare ha de dataene som er nyttige for å kunne utføre reglene på best mulig måte.
Det er adapter laget, illustert over, sitt ansvar å oversette domene data frem og tilbake.
Fordelene med dette er at man kan teste reglene i isolasjon, og at det er klare separate linjer mellom de forskjellige ansvarsområdene, som gjør koden enklere å endre og vedlikeholde. Å endre konkrete rammeverk og teknologier skal være rimelig enkelt.
Ansvaret til hver av lagene
1. Domain Layer/Entities
Det innerste laget. Inneholder business objekter som "encapsulater" business reglene. Dette laget skal ikke ha noen viten om eksterne greier som databaser og UI. Det skal kun være objekter, guidet av Domain Driven Design, som inneholder business logikk for det domene man jobber med.
1.5 Domain service
"Valgfritt" lag. Om man har to entiteter som trengs sammen for å overholde en regel, så kan disse legges i et domene service lag, mellom application service og domene modellen. F.eks. Sjekk at distributør A har tilgang til produkt B.
Noe som typisk ikke skal her er ting som å validere at distributør A finnes i systemet. Dette bør ligge i application service. Det er en enkel validering for å sjekke at det du spør om gir mening kontekst av systemet.
2. Application Layer/Use Cases
Er en "bro" mellom det ytre UI/Infrastruktur laget og domene laget.
Det brukes typisk til ting som
- Orkestrering: Dersom man skal registrere en bruker involverer dette ofte flere steg. Validere bruker input, opprette en ny "User" entitet og lagre den til databasen
- DTOs og Assemblers: Dersom det ytre laget, i.e. UI, krever at data er i et spesifikt format så kan Application Layer typisk ha ansvar for å konvertere domene entiteter til Data Transfer Objects (DTOs). Dette kan være å "assemble" en DTO fra flere entiteter eller "disassemble" en DTO til entiteter.
- Kalle infrastruktur tjenester: Ting som å sende eposter, snakke med tredjeparts APIer osv
Her kan man også typisk definere interfaces man trenger. F.eks. IProductRepository, om man trenger å lagre produkter. Disse kan så implementeres i adapter laget
3. Interface Adapters/Controllers
Her er de abstraksjonene som skal snakke med verden utenfor. Ting som controllere for http requests, repositories for persistens osv.
Frameworks and Drivers
Her ligger de faktiske konkrete rammeverkene og verktøyene hvor informasjonen havner. Ting som web-rammeverk og databasen ligger her.
Flyt
En sentral regel i Clean Architechture er "The Dependency Rule": Dependencies kan bare peke innover sirkelen. Dette kan oppnås ved å bruke Dependency Injection.
Det indre laget definerer et interface. De ytre lagene implementerer interfacet. Når man da f.eks. skal lagre noe i Use Cases laget, så vil Adapters laget injecte sin implementasjon av interfacet.
Flyten innover betyr ikke at dataflyten kun kan være innover. Use Case laget må flyte data opp til Adapter laget for å kunne lagre det. Men det er konseptet med at det indre laget ikke kjenner til laget utenfor som er viktig. Interfacet defineres med datatyper den kjenner til. Det er adapter laget sin jobb å oversette dette til database modellen.