Detaljerat innehåll i blocken:
Clean Code
Vad är kodkvalitét? Varför är det viktigt? Vi tar avstamp från Uncle Bobs bok, klassikern ”Clean Code”. Vi kommer även in på hur vi upprätthåller god kvalitét i vår kod, med både pro- och reaktiva aktiviteter.
- Genomgång av boken och principer.
- Tekniker för att ”hålla rent”.
- Att synliggöra renhållningen.
- Continuous Inspection.
Lösningsarkitektur
Vi går igenom systemlösningar och lösningsmönster. Dels ”yttre” (deployment) arkitektur i form av Monoliter, Modulära monoliter och Mikrotjänster, dels ”inre” arkitektur i form av te x Hexagonal arkitektur. Som vanligt ser på för- och nackdelar med olika lösningar. Vad är viktigt hos respektive lösning. Varför och när passar vissa typer av lösningar.
- Vad är Arkitekturmönster?
- Etablerade arkitekturer (Från POSA, dvs Lager, Microkernel, Mvc, Pac, Pipes-n- Filters mfl).
- Moderna arkitekturer (Containers, Microservices, Modular-Monolith, Hexagonal arkitektur).
- Mikrotjänst-mönster (Gateways och Service Mesh, ELK-Stack mfl)
- Onion/Clean/DDD (DDD-arkitekturen som också är en Hexagonal Arkitektur, tas upp i sitt block). - CCCs, Cross Cutting Concerns, (Arkitekturella mekanismer)
- Cachning - BI/DW/ETL med tex Mapreducing och Snowflaking.
- Antimönster.
- ELT (Obs inte ETL) med Datastreams och Datalakes tas i huvudsak upp i EDA-blocket.
- Data Architecture med sina Data Produkter och Data.
Integrationsarkitektur
Det första många tänker på är API:er, dvs fråga-svars-integrationer. Det är en viktig del och till det kommer hur man t.ex. tar fram ett REST-API och saker som följer med det, t ex. Idempotency mm. Blocket handlar även om asynkrona integrationer och ”långa” transaktioner.
- Var är Integrationsarkitektur?
- EIP, Bibeln för integrationsarkitekter.
- Integrationsmönster och Integrationsplattformar.
- Hur ta fram en integration?
- Integrationskontrakt.
- API:er
- REST/SOAP/gRPC/GraphQL.
- Idempotency.
- REST-Designsövning och genomgång.
- Gateway mönster och Federerad inloggning.
- Långa transaktioner.
- SAGA (orkestrerad och koreograferad).
- MFT.
Domain-Driven Design, DDD
DDD kom tillbaka i mitten av tio-talet, efter att varit ”bortglömt” i nära ett decennium. Orsaken till det stavas främst microservices. Behovet av att dela upp alltför stora system och databaser i dels ansvarsområden, datastrukturer och kod har blivit större och större. Den strategiska komponenten i DDD betonar ansvarsfördelningen och det administrativa förhållandet mellan delar. Även den bakomliggande tekniken har mognat. Det är t ex inte självklart hur persisteringen ska göras idag. DDD är ett sätt att adressera dessa punkter. Vi går igenom DDD:s strategiska och taktiska design.
- Genomgång av komponenterna i Strategisk design, som tex Context Mapping.
- Två modelleringsövningar. Domain-Driven Design.
- Taktisk Design.
- Genomgång av de taktiska komponenterna, som t ex Aggregat.
- Två modelleringsövningar. Domain-Driven Design
- DDD Events (Domain events och Integration events)
- DDD arkitektur (DDDs variant av Hexagonal arkitektur).
- Summering DDD.
Event Driven Architecture, EDA
Dagens krav på att hela tiden slippa fråga efter information och istället bli notifierad om att något har hänt (dvs gå från ”Pull to Push”) och löst kopplade system, ställer stora krav på arkitekturen och på hur vi modellerar våra system.
- Power of Events, Luckham.
- Varför/Motivering till EDA och grundläggande kommunikationsbehov. (Push vs Pull).
- EDA och dess stilar.
- Mönster/Topologier.
- Meddelanden (olika uppbyggnad och vanliga mönster, så tex ECST). Event Driven Architecture.
- Kafka Overview (Topics, Replicated Partitions, Avro-schemas, Connectors, Windowing).
- CQRS - Arkitekturmönstret, dess komponenter samt, motivering och eventuella följder.
- Eventsourcing.
- Arkitekturmönstret, dess komponenter, samt motivering och eventuella följder.
- CEP och Funktionell Programmering, Marble Diagram mm. Event Driven Architecture
- Event Storming, dels vad det är, dels dess delar.
Frontendarkitektur
Detta ämne har gått från att vara en del av lösningsarkitektur till att ha blivit en egen kategori/block.
- SPAs, PWAs, MFEs, Rx och strömmar, CSRs vs SSR (som börjar komma tillbaka ).
- Tillståndshantering.
- För- och Nackdelar med olika lösningar.
Att jobba som arkitekt
Vi har lärt oss språket, mönstren och de olika arkitekturerna. Här knyter vi ihop delarna. Vi går igenom hur vi jobbar som arkitekter idag. Hur vi gör tradeoff-analyser och hur vi tar beslut och dokumenterar?
- Mantra (”Create Vision”,”Use Guardrails”, "Continuous Architecting", ”Imprint Culture” mm).
- Tradeoff analyser och beslutsloggar (ADR). - Hantering av QoS: Nedbrytning av IFK:er/”illities” och vidare (SLO, SLI, SLA:er).
- Tradeoffs- och Beslutsövningar. Att jobba som arkitekt.
- Varför, Vad och När dokumenterar vi?
- Dokumentation (Formella notationer och diagram, som tex Archimate, BPMN, UML, Kruchten 4+1, C4).
- Automatisering. ”DaC”, Documentation/Diagram As Code och slutligen AIs intåg på denna front.
