Förståelse för Clean Architecture

Mål med Clean Architecture

Clean Architecture syftar till att skapa programvara som är lätt att förstå, underhålla och testa. Den betonar separation av ansvar och skapande av tydligt definierade gränser mellan olika delar av applikationen. Denna separation möjliggör enklare testning av individuella komponenter.

Fördelar med Clean Architecture

• ➤ Ramverksoberoende: Kan användas med ASP.NET (Core), Java, Python osv., utan att vara beroende av något specifikt mjukvarubibliotek eller proprietär kodbas.
• ➤ Testbarhet: Kan användas med ASP.NET (Core), Java, Python osv., utan att vara beroende av något specifikt mjukvarubibliotek eller proprietär kodbas.
• ➤ UI-Oberoende: Logik hålls utanför UI, vilket gör det enkelt att byta teknologier, t.ex. från Angular till React eller Blazor.
• ➤ Databasoberoende: Separera tydligt dataåtkomstansvar, vilket underlättar ändringar från SQL Server till CosmosDB.
• ➤ Oberoende från externa system: Kärnan är helt isolerad från omvärlden, vilket säkerställer lång livslängd och enkel uppdatering.
• ➤ Löst kopplade komponenter: Främjar lös koppling mellan komponenter och lager, vilket ökar underhållbarhet och skalbarhet.

Clean Architecture: Den Stora Bilden

• 1. Affärslogik och Applikationsmodell i Centrum: Säkerställer att viktiga aspekter av mjukvaran är oberoende och väl definierade.
• 2. Omvänd beroende: Affärslogik är inte beroende av dataåtkomst eller infrastrukturproblem; istället är infrastrukturen beroende av Applikationskärnan.
• 3. Tydliga Abstraktioner i Applikationskärnan: Definierar klara abstraktioner (gränssnitt) som representerar väsentliga kontrakt.
• 4. Implementering i Infrastruktur-lagret: Konkreta implementationer finns i Infrastruktur-lagret, som hanterar dataåtkomst, externa tjänster osv.
• 5. Inåtriktad Flöde av Beroenden: Alla beroenden flödar inåt mot Applikationskärnan, vilket säkerställer strikt separation av ansvar.

Lager i Clean Architecture

• ➤ Domänlager: Kärnan i arkitekturen, implementerar affärslogik utan beroenden på andra lager.
• ➤ Applikationslager: Mellanlager, hanterar data mellan domän- och presentations-/infrastrukturlager.
• ➤ Infrastrukturlager: Innehåller klasser för åtkomst till externa resurser som filsystem, webbtjänster och databaser.
• ➤ Presentationslager: UI-kod, använder ASP.NET Core för att bygga gränssnitt.

Domain Driven Design (DDD)

Domain-Driven Design (DDD) är en uppsättning principer och mönster för att designa programvara som fokuserar på kärndomänen och dess logik. DDD betonar samarbete mellan tekniska och domänexperter för att iterativt förfina en konceptuell modell som adresserar komplexa affärskrav. Nyckelkoncepten i DDD inkluderar:

• Entiteter:	Objekt med en distinkt identitet som genomgår olika tillstånd i systemet.
• Värdeobjekt:	Oföränderliga objekt som representerar en beskrivande aspekt av domänen utan konceptuell identitet.
• Aggregat:	En grupp av domänobjekt som behandlas som en enhet för datamodifikationer.
• Repositorier:	Mekanismer för att kapsla in lagring, hämtning och sökbeteende, som imiterar en samling av objekt.

Testning i Clean Architecture

Testning i Clean Architecture innebär att testa varje lager oberoende för att säkerställa att alla komponenter fungerar korrekt och interagerar på rätt sätt med varandra. Detta är ett mycket viktigt steg och reducerar avsevärt komplexiteten.

1. ➤ Mocking: Skapa objekt som simulerar beteendet hos verkliga objekt. I detta fall kan du mocka dina databas-repositorier utan den faktiska implementationen.
2. ➤ Dependency Injection: Passera beroenden (som repositorier) till dina användningsfall eller tjänster för att underlätta enhetstestning.
3. ➤ Isolering: Säkerställa att varje test är oberoende och inte är beroende av tillstånd eller data från andra tester.

Implementering av Clean Architecture

• 1. Konfiguration av Domänlager: Definiera entiteter, enums, undantag, gränssnitt och typer.
• 2. Konfiguration av Applikationslager: Skriv affärslogik och tjänstgränssnitt, bibehåll lös koppling.
• 3. Konfiguration av Infrastrukturlager: Implementera dataåtkomst och externa resursinteraktioner baserade på kärninterfaces.
• 4. Konfiguration av Presentationslager: 4. Konfiguration av Presentationslager:

Principer att Följa

1. Separation av Ansvar:	Undvik att blanda olika kodansvar i samma metod/klass/projekt.
2. Enkel Ansvarighet:	Varje modul/komponent bör ha endast en anledning att ändras.
3. Undvik Upprepning (DRY):	Undvik duplicerad kod eller logik.
4. Omvända Beroenden:	Högnivåpolicyer bör inte bero på lågnivådetailler; använd beroendeinjektion för att främja lös koppling.

Slutsats

Clean Architecture erbjuder en robust grund för att bygga mikrotjänster med .NET Core Web API. Genom att följa principer för separation av ansvar och beroendeinversion kan utvecklare skapa skalbara, underhållbara och testbara applikationer. Att omfamna Clean Architecture säkerställer en solid grund för de ständigt föränderliga kraven inom modern programvaruutveckling.

Läs mer på vår GitHub