Kartenstapel

"Der kulturelle und architektonische Wandel durch moderne IT-Prozesse (z. B. Cattle vs. Pets, Conway's Law, Bounded Context, Ubiquitous Language, 3 Amigos)."

"Pets (Haustiere) werden manuell gepflegt und bei Fehlern repariert. Cattle (Nutztiere) sind zustandslos und austauschbar bei Fehlern werden sie automatisiert gelöscht und neu aufgesetzt."

"Die strikte Zustandslosigkeit einzelner Instanzen. Daten werden in ausgelagerten Diensten (Datenbanken, Caches) gespeichert, um freie Skalierung zu ermöglichen."

"Distribution (Verteilung): Systeme sind über mehrere Knoten und Standorte verteilt, um Ausfallsicherheit und Lastverteilung zu gewährleisten."

"Elasticity (Elastizität): Die Fähigkeit, Ressourcen automatisch an den aktuellen Bedarf anzupassen (horizontale Skalierung / Scale-Out)."

"Automated (Automatisierung): Steuerung, Deployment, Skalierung und Reparatur erfolgen vollständig über automatisierte Skripte und Plattformen."

"Loose Coupling (Lose Kopplung): Komponenten interagieren über minimale, stabile Schnittstellen und sind unabhängig voneinander änderbar."

"1. Containerisierung (z.B. Docker), 2. Dynamische Orchestrierung (z.B. Kubernetes), 3. Microservices-Architekturen."

"Traditionelle Anwendungen werden unverändert in virtuelle Maschinen in der Cloud verschoben (Lift-and-Shift), ohne Cloud-Vorteile aktiv zu nutzen."

"Volle Cloud-Native-Nutzung: Zustandslosigkeit, automatische Skalierung zur Laufzeit und dynamische Ressourcenallokation."

"Infrastructure as a Service. Es bietet grundlegende IT-Ressourcen wie virtuelle Server, Speicher und Netzwerke (z.B. AWS EC2)."

"PaaS (Platform as a Service) stellt eine Entwicklungsumgebung für eigene Software bereit. SaaS (Software as a Service) bietet fertige Endanwendungen über den Browser (z.B. Microsoft 365)."

"Entwickler schreiben nur reinen Funktionscode. Die Infrastruktur wird erst beim Event-Aufruf instanziiert, exakt für die Laufzeit berechnet und danach sofort wieder gelöscht."

"Eine Kultur der Automatisierung und gemeinsamen Eigenverantwortung, die die Zusammenarbeit zwischen Entwicklung (Dev), Betrieb (Ops) und QA optimiert."

"Die Optimierung des Wertstroms von links nach rechts. Arbeit wird sichtbar gemacht (Kanban), das Work in Process (WIP) limitiert und manuelle Übergaben eliminiert."

"Die Etablierung schneller Rückmeldeschleifen von rechts nach links. Fehler werden per Telemetrie sofort sichtbar gemacht und die Pipeline bei Fehlern gestoppt (Andon-Kordel)."

"Chaos Engineering (z.B. gezieltes Abschalten von Servern im Live-Betrieb, um die Resilienz zu testen)."

"Bei CI wird Code mehrmals täglich in ein Repository gepusht und automatisch gebaut/getestet. Bei Continuous Delivery liegt am Ende ein deploybares Artefakt bereit, die Live-Freigabe erfolgt aber manuell."

"Bei Continuous Delivery erfolgt die Freigabe in die Produktion manuell auf Knopfdruck. Bei Continuous Deployment wird jede stabile Änderung vollautomatisch ohne Zwischenstopp live eingespielt."

"Qualitätssicherung und Tests werden im Lebenszyklus so früh wie möglich nach vorne (""links"") verlagert, um Defekte kostengünstig vor dem Release zu finden."

"Unit-Tests -> Integrations-Tests -> System-Tests -> UI- / Akzeptanz-Tests."

"Weil Tests weiter oben (z.B. UI-Tests) langsamer in der Ausführung, komplexer im Aufbau und deutlich teurer in der Wartung sind."

"Das wiederholte Testen bereits funktionierender Softwareteile nach einer Änderung, um sicherzustellen, dass keine neuen Fehler eingebaut wurden."

"Die Praxis, nicht nur Applikationscode, sondern auch Infrastruktur (IaC), Testskripte und Pipeline-Konfigurationen als versionierten Text-Code zu verwalten."

"Dass die mehrfache Ausführung eines Skripts oder Befehls unter identischen Bedingungen immer zum exakt selben System-Zielzustand führt."

"Die kontinuierliche Produktverbesserung im Live-Betrieb anhand von Metriken, datengetriebenen Experimenten und z.B. A/B-Tests."

"""Die Architektur eines Softwaresystems spiegelt die Kommunikationsstrukturen der Organisation wider, die es erschafft."" (Organization follows Architecture)."

"Kleine, interdisziplinäre und autonome Einheiten (5-9 Personen), die die vollständige Ende-zu-Ende-Verantwortung für einen fachlichen Service tragen."

"Die Aufteilung einer Anwendung in kleine, lose gekoppelte, unabhängig voneinander deploybare Dienste, die um fachliche Fähigkeiten herum gebaut sind."

"Das Prinzip, dass jeder Microservice die Datenbanktechnologie nutzt, die am besten zu seinen fachlichen Anforderungen passt (z.B. NoSQL für Graphen, SQL für Finanzen)."

"Das Maß der Abhängigkeit zwischen verschiedenen Software-Komponenten oder Services. Angestrebt wird eine lose Kopplung."

"Das Maß für den inneren Zusammenhalt der Aufgaben innerhalb einer Komponente. Angestrebt wird eine hohe Kohäsion (Single Responsibility)."

"Das strategische Herzstück des Unternehmens. Sie ist hochkomplex, liefert den eigentlichen Wettbewerbsvorteil und muss zwingend intern entwickelt werden (Make)."

"Sie unterstützt das Kerngeschäft, bietet aber keinen direkten Wettbewerbsvorteil. Sie ist mäßig komplex und ein Kandidat für Outsourcing."

"Ein Standard-Geschäftsproblem ohne Differenzierungspotenzial (z. B. Buchhaltung). Hier gilt die Devise: Standardsoftware am Markt einkaufen (Buy)."

"Eine explizite Grenze innerhalb einer Domänenarchitektur, innerhalb derer alle Modelle und Begriffe eine absolut eindeutige, widerspruchsfreie Bedeutung haben."

"Eine gemeinsame, präzise und allgegenwärtige Fachsprache, die von Fachexperten und Entwicklern innerhalb eines bestimmten Bounded Contexts gleichermaßen genutzt wird."

"Weil Begriffe in unterschiedlichen Abteilungen verschiedene Bedeutungen haben (z.B. ""Kunde"" im Marketing = Lead im Versand = Lieferadresse). DDD löst dies durch Bounded Contexts."

"Der Upstream ist der Zulieferer, dessen Änderungen an Datenstrukturen sich direkt auf das nachgelagerte System (Downstream) auswirken."

"Das nachgelagerte Team (Downstream) passt sich dem Datenmodell des Zulieferers (Upstream) bedingungslos und ohne Übersetzung an."

"Eine Übersetzungsschicht (Korruptionsschutzschicht), die fremde Datenstrukturen in das eigene Domänenmodell übersetzt, um dieses sauber zu halten."

"Ein Upstream-System bietet eine standardisierte, stabile und offen dokumentierte Schnittstelle (z. B. OpenAPI) für viele Consumer an."

"Ein standardisiertes, dokumentiertes Datenformat (z.B. JSON-Schema), das ein OHS zur Kommunikation nutzt."

"Zwei Teams teilen sich eine gemeinsame Datenbasis oder Code-Bibliothek (Kern). Änderungen müssen strikt synchronisiert werden."

"Zwei Teams sind wechselseitig voneinander abhängig. Eines kann ohne das andere kein Release durchführen Kooperation ist zwingend synchron."

"Eine Entität besitzt eine eindeutige, dauerhafte Identität (ID) über ihren Lebenszyklus hinweg. Ein Wertobjekt hat keine Identität, ist unveränderlich und wird rein durch seine Attribute definiert."

"Ein Geldbetrag (Wert: 50, Währung: EUR) oder eine Adresse. Ändert sich ein Wert, wird das Objekt komplett ersetzt."

"Eine logische Zusammenfassung von Entitäten und Wertobjekten, die eine gemeinsame Transaktionsgrenze bildet, um die Datenkonsistenz zu sichern."

"Ausschließlich über die Aggregatwurzel (Aggregate Root). Externe Objekte referenzieren das Aggregat nur über die ID der Wurzel."

"Sie kapselt die komplexe Logik bei der Erzeugung neuer, valider Aggregate, um die Geschäftslogik zu entlasten."

"Es kapselt den tatsächlichen Datenbankzugriff und simuliert für die Geschäftslogik eine reine In-Memory-Sammlung von Aggregaten."

"Die Geschäftslogik steht technologieunabhängig im Zentrum. Sie definiert abstrakte Schnittstellen (Ports). Die technische Außenwelt dockt über konkrete Adapter an."

"Ein Inbound-Port nimmt Anfragen von außen entgegen (z.B. API-Aufruf). Ein Outbound-Port wird von der Domäne aufgerufen, um Daten nach außen zu geben (z.B. Datenbank-Persistierung)."

"Eine agile Methode zur Beschreibung des Systemverhaltens durch konkrete Beispiele in natürlicher Sprache, um ein gemeinsames Verständnis aller Beteiligten zu sichern."

"Die Gherkin-Syntax: Given (Ausgangssituation) -> When (Aktion) -> Then (Erwartetes Ergebnis)."

"Business/Product Owner (fachliche Sicht), Developer (technische Sicht) und Tester (Qualitätssicht)."

"Da die verhaltensbasierten Akzeptanztests in natürlicher Sprache geschrieben sind und kontinuierlich ausgeführt werden, spiegeln sie immer den exakten Ist-Zustand des Systems wider."

"Architekturentscheidungen so spät wie möglich (wenn zwingend notwendig anhand von Fakten) treffen und Systeme explizit für stetige Veränderung designen."

"Ein Domino-Effekt in verteilten Systemen, bei dem der Ausfall eines einzelnen Services durch Überlastung oder Timeouts nachfolgend weitere Services mit in den Absturz reißt."

"Er überwacht Service-Aufrufe. Bei zu vielen Fehlern öffnet sich der Schalter (Open) und blockiert Folgeanfragen sofort mit einem schnellen Fallback, um Kaskadenfehler zu verhindern."

"1. Closed (Normalbetrieb), 2. Open (Fehlerzustand, blockiert Anfragen), 3. Half-Open (Testphase nach Wartezeit)."

"Es werden vereinzelte Testanfragen durchgelassen. Funktionieren sie fehlerfrei, schließt sich der Schalter (Closed). Treten Fehler auf, öffnet er sich wieder (Open)."

"Die strikte Partitionierung von Ressourcen (z. B. Threads, CPUs) für verschiedene Systemkomponenten. Fällt ein Bereich aus, bleibt das restliche System geschützt."