Kapitel 14 und 15
Domain-driven Design
Domain Driven Design (DDD) beschreibt einen Prozess und unterstützende Methodiken, die einer Philosophie der Ausrichtung der Software-Entwicklung an der Fachlichkeit folgen. DDD ist dabei Vorgehensmodell-agnostisch und kann mit unterschiedlichen (agilen) Vorgehensmodellen verwendet werden. Dabei durchläuft man strategische und taktische Entwurfsschritte, die methodisch unterstützen, eine Lösung im Lösungsraum zu definieren.
Auf Ebene des strategischen Designs werden dabei in einem ersten Schritt Subdomänen identifiziert. Entwicklungs- und Verfeinerungsaufwände werden dabei primär in Core und teilweise in Supporting Subdomains investiert. In diesen Bereichen werden sogenannte Bounded Contexts definiert, die letztlich den technischen Lösungsraum strukturieren und bspw. auf Microservices abgebildet werden können.
Bounded Contexts bilden somit den Übergang vom strategischen zum taktischen Design. Modelle in verschiedenen Bounded Contexts können dabei grundsätzlich unabhängig voneinander entwickelt und implementiert werden. Bounded Contexts sind zwar unabhängig von einander entwickelbar, aber nicht vollkommen isoliert voneinander. Auch Bounded Contexts müssen miteinander interagieren. Infolgedessen gibt es immer Berührungspunkte zwischen Bounded Contexts, die als Verträge bezeichnet werden und in Form von Context Maps visualisiert werden können. Dabei kann es Machtgefälle zwischen Bounded Contexts geben, die in Form von Kooperations- oder Customer-Supplier-Abhängigkeiten festgelegt werden sollten. Diese Context Maps bilden den Übergang vom Problemraum (strategisches Design) zum Lösungraum (taktisches Design). Im Bereich des taktischen Designs werden Bounded Contexts dann softwaretechnisch weiter verfeinert. Hier greift man üblicherweise auf bekannte Architekturmuster (wie z.B. Layered Architecture, Ports & Adapters oder CQRS) sowie Entwurfsmuster (wie Domain Model, Event Sourcing, Extract Transform Load, Active-Record) zurück.
Slides
| Inhalte | Downloads | |
|---|---|---|
| Slides Unit 09 |
Domain Driven Design
|
PDF PPTX |
Patterns und Best Practices
Auflistung aller Patterns und Best Practices dieses Buchs.
| Konzept | Pattern / Best Practice | Abschnitt(e) | Anmerkungen |
|---|---|---|---|
| Workload | Statische Last | [-@sec:workload] | eher ungeeignet |
| Workload | Steigende / sinkende Last | [-@sec:workload] | ggf. geeignet |
| Workload | Zufällige Last | [-@sec:workload] | sehr geeignet |
| Workload | Einmalige / seltene Last | [-@sec:workload] | max. geeignet |
| Pay-as-you-go | Ressourcen-Effizienz | [-@sec:resource-sizes] | Reduktion der Komponenten-Größe und / oder Zuteilungsdauer |
| DevOps | Deployment Pipelines | [-@sec:devops-flow;-@sec:flaschenhaelse-minimieren;-@sec:pipelines-as-code;-@sec:ms-principle2] | Prinzipien des Flow (Automatisierung) |
| DevOps | Orchestrierungs-Plattformen | [-@sec:orchestrierungs-plattformen;-@sec:orchestration;-@sec:kubernetes;-@sec:ms-principle2] | Prinzipien des Flow (Automatisierung) |
| DevOps | Telemetriedaten-Konsolidierung | [-@sec:devops-feedback;-@sec:telemetrie-konsolidierung;-@sec:telemetry-consolidation;-@sec:ms-principle7] | Prinzipien des Feedback (Observability) |
| DevOps | Release-Risiken minimieren | [-@sec:release-strategien;-@sec:traffic-management] | Blue/Green Releases, Canary Releases, Rolling Updates, Feature Schalter |
| Cloud-native | Scale-Out not Scale-Up | [-@sec:cna-definition;-@sec:faktor-689;-@sec:ms-scaling;-@sec:ms-load-balancing] | Horizontale Skalierung |
| Cloud-native | Elastizität durch Auto-Skalierung | [-@sec:cna-definition;-@sec:k8s-auto-scaling;-@sec:faas-event-driven-autoscaling;-@sec:ms-scaling;-@sec:ms-load-balancing] | Horizontale Skalierung |
| Cloud-native | In sich geschlossene Komponenten (Container) | [-@sec:cna-definition;-@sec:container;-@sec:cre;-@sec:container-image-build] | Stateless |
| Cloud-native | Isolation zustandsbehafteter Komponenten | [-@sec:cna-definition;-@sec:scaling-state] | Stateful |
| Cloud-native | Betrieb auf elastischen Plattformen | [-@sec:cna-definition;-@sec:orchestrierungs-plattformen;-@sec:orchestration;-@sec:ms-principle2] | z. B. Kubernetes |
| Pipeline | Deployment Pipelines as Code | [-@sec:flaschenhaelse-minimieren;-@sec:pipelines-as-code;-@sec:ms-principle2] | Automatisierung |
| Pipeline | Phasen Pipelines | [-@sec:phasen-pipelines] | Build - Test - Deploy |
| Pipeline | Gerichtete Pipelines | [-@sec:gerichtete-pipelines] | Beschleunigung von Pipelines |
| Pipeline | Hierarchische Pipelines | [-@sec:hierarchische-pipelines] | Komplexe Systeme, Monorepositories |
| Pipeline | Steuerung von Pipelines | [-@sec:steuerung-von-pipelines] | Build-Trigger, Umgebungsvariable, Environments |
| Continuous Integration | Git-Flow Branching | [-@sec:gitflow] | Tendenz zu vielen Branches |
| Continuous Integration | GitHub-Flow Branching | [-@sec:github-flow] | nur für sehr einfache Projekte |
| Continuous Integration | Trunk-basiertes Branching | [-@sec:trunk-based] | pragmatisches Branching |
| Infrastructure as Code | Hardware Virtualisierung | [-@sec:hw-virtualisierung] | Para-/Voll-Virtualisierung |
| Infrastructure as Code | Immutable Infrastructure | [-@sec:immutable-architecture] | Infrastrukturparadigma |
| Infrastructure as Code | Provisionierung | [-@sec:iac-ansaetze] | Deklarativ und imperativ, Push und Pull von Konfigurationen |
| Infrastructure as Code | Single-VM Provisionierung | [-@sec:single-vm-provisionierung] | Entwicklungs- und Testumgebungen, z. B. Vagrant |
| Infrastructure as Code | Multi-VM Provisionierung | [-@sec:multi-vm-provisionierung] | Produktions- und Testinfrastrukturen, z. B. Terraform |
| Container | Prozessisolation | [-@sec:cre;-@sec:container-runtime] | Kernel Namespaces, Process Capabilities, Control Groups, Union Filesystem |
| Container | Container as Code | [-@sec:container-image-build;-@sec:faktor-1;-@sec:faktor-5] | Dockerfile, Codebase |
| Container | Umgebungsvariablen | [-@sec:faktor-23] | Konfiguration von 12 Faktor Apps |
| Container | Port-Binding | [-@sec:faktor-47] | Komposition von 12 Faktor Apps |
| Container | Skalierung über Prozesse | [-@sec:faktor-689;-@sec:ms-load-balancing] | Skalierung von 12 Faktor Apps |
| Container | Stdout-Logging | [-@sec:faktor-10] | Beobachtbarkeit von 12 Faktor Apps |
| Container | Image-Shrinking | begleitende Labs | Command Chaining, Small Base Images |
| Scheduling | Bin Packing | [-@sec:simple-scheduling] | Einfacher Algorithmus, z. B. Docker |
| Scheduling | Spreading | [-@sec:simple-scheduling] | Einfacher Algorithmus, z. B. Kubernetes |
| Scheduling | Multidimensionales Scheduling | [-@sec:drf-scheduling] | z. B. Dominant Resource Fairness (Mesos) |
| Scheduling | Kapazitätsbasiertes Scheduling | [-@sec:capacity-scheduling] | Angabe min. und max. Ressourcen (z. B. Yarn) |
| Scheduling | Monolithisches Scheduling | [-@sec:monolithic-scheduler] | z.B. Kubernetes |
| Scheduling | 2-Level Scheduling | [-@sec:two-level-scheduler] | z.B. Mesos |
| Scheduling | Shared State Scheduling | [-@sec:shared-state-scheduler] | z.B. Omega |
| Orchestration | Blueprints | [-@sec:blueprinting;-@sec:k8s-blueprints] | z. B. Manifest-Dateien in Kubernetes |
| Orchestration | Regelkreis-basierte Überwachung | [-@sec:rule-based-orchestration] | z. B. Controler in Kubernetes (Desired vs. Current State) |
| Orchestration | Deployment Workload | [-@sec:workload-heterogenität;-@sec:k8s-deployments;-@sec:scheduling-constraints] | kontinuierlich verfügbare Services |
| Orchestration | Job Workload | [-@sec:workload-heterogenität;-@sec:k8s-jobs;-@sec:scheduling-constraints] | einmalig/periodisch auszuführende Tasks |
| Orchestration | Daemon Workload | [-@sec:workload-heterogenität;-@sec:k8s-daemonsets;-@sec:scheduling-constraints] | Auf allen Knoten einer Plattform auszuführende Hintergrund-Tasks |
| Orchestration | Stateful Set Workload | [-@sec:workload-heterogenität;-@sec:k8s-statefulsets:-@sec:scheduling-constraints] | Eindeutig über Re-Schedulings hinaus identifizierbare Komponenten |
| Orchestration | Horizontale Skalierung (Ressourcen-Verbrauch) | [-@sec:cna-definition;-@sec:faktor-689;-@sec:k8s-auto-scaling;-@sec:ms-scaling;-@sec:ms-load-balancing] | Horizontal Pod Autoscaler |
| Orchestration / FaaS | Horizontale Skalierung (Ereignis-basiert) | [-@sec:cna-definition;-@sec:faktor-689;-@sec:k8s-auto-scaling;-@sec:faas-event-driven-autoscaling;-@sec:ms-scaling;-@sec:ms-load-balancing] | KEDA, FaaS |
| Orchestration | Service Exposing (Plattform-intern) | [-@sec:k8s-service-exposing] | z. B. Kubernetes Service |
| Orchestration | Service Exposing (Plattform-extern) | [-@sec:k8s-service-exposing] | z. B. Kubernetes Ingress |
| Orchestration | Health-Checking | [-@sec:health-checking;-sec:ms-principle6] | z. B. Kubernetes Probes |
| Orchestration | Volume Claiming | [-@sec:persistenz] | Anforderung von persistentem Storage |
| Orchestration | Workload Isolation | [-@sec:k8s-isolation] | Multi-Tenancy mittels Namespaces, Quotas, Network Policies |
| FaaS | Scale-to-Zero | [-@sec:faas] | Time-Sharing von schwach genutzten Ressourcen |
| FaaS | Funktions-basierte Workloads | [-@sec:faas-plattformen;-@sec:faas-programmiermodell] | Nanoservices |
| FaaS | Funktions-Trigger | [-@sec:faas-programmiermodell] | Event-gesteuertes Computing Modell |
| FaaS | Plattform-agnostische Funktionsdefinition | [-@sec:faas-agnostic] | Lösung für (noch) fehlende Standardisierung |
| Microservice | You-build-you-run-it | [-@sec:microservices;-@sec:ms-characteristics] | Produkt- statt Projekt-Philosophie |
| Microservice | Unabhängige Aktualisierbarkeit von Komponenten | [-@sec:ms-characteristics;-@sec:ms-principle5] | techn. Voraussetzung für Microservices |
| Microservice | Lose Kopplung von Komponenten | [-@sec:ms-characteristics] | techn. Voraussetzung für Microservices |
| Microservice | Datenbank-basierte Integration | [-@sec:cna-definition;-@sec:scaling-state;-@sec:shared-database] | Shared State, oft enge Kopplung |
| Microservice | (g)RPC-basierte Integration | [-@sec:rpc] | Request-Response, mittlere Kopplung |
| Microservice | REST-basierte Integration | [-@sec:rest] | Request-Response, geringe Kopplung |
| Microservice | Queueing | [-@sec:event-based] | Load Balancing, minimale Kopplung |
| Microservice | Publish/Subscribe | [-@sec:event-based] | Fan-Out, minimale Kopplung |
| Microservice | Reactive Systems | [-@sec:event-based] | Siehe auch Reaktives Manifest |
| Microservice | API-Versioning | [-@sec:api-versioning] | Mittel der letzten Wahl |
| Microservice | Circuit Breaker | [-@sec:ms-arch-safety;-@sec:circuit-breaker;-@sec:ms-principle6] | Architectural Safety Pattern |
| Microservice | Bulkhead | [-@sec:ms-arch-safety;-@sec:bulkhead;-@sec:ms-principle6] | Architectural Safety Pattern |
| Microservice | Idempotente API-Operationen | [-@sec:ms-arch-safety;-@sec:idempotent-api;-@sec:ms-principle6] | Architectural Safety Pattern |
| Microservice | Load Balancing | [-@sec:k8s-service-exposing;-@sec:ms-load-balancing] | Performance Pattern |
| Microservice | Horizontale Skalierung | [-@sec:ms-scaling;-@sec:ms-principle4;-@sec:ms-load-balancing] | Performance Pattern |
| Microservice | Clientseitiges Caching | [-@sec:caching] | Performance Pattern: Clientseitig, Serverseitig, Proxy-basiert |
| Microservice | Scaling for Reads | [-@sec:cna-definition;-@sec:scaling-state;-@sec:scaling-for-reads] | Stateful Scalability Pattern |
| Microservice | Scaling for Writes | [-@sec:cna-definition;-@sec:scaling-state;-@sec:scaling-for-writes] | Stateful Scalability Pattern |
| Microservice | CQRS | [-@sec:cna-definition;-@sec:scaling-state;-@sec:scaling-with-cqrs;-@sec:ddd-cqrs] | Stateful Scalability Pattern |
| Microservices / Serverless | API-Gateway | [-@sec:api-gateways] | API-Endpunkt-Konsolidierung |
| Serverless | Choreography by Client-Devices | [-@sec:ms-principle4;-@sec:serverless-effect] | Vermeidung des Double-Spending Problems |
| Serverless | Backend as a Service | [-@sec:serverless-effect] | Dezentralisierung |
| Observability | Telemetriedaten-Konsolidierung | [-@sec:ms-principle7;-@sec:telemetry-consolidation] | Single Source of Observability-Data |
| Observability | Telemetriedaten-Visualisierung | [-@sec:ms-principle7;-@sec:telemetry-consolidation] | Birds-Eye View |
| Observability | Logging-Instrumentierung | [-@sec:ms-principle7;-@sec:logging] | White-Box Instrumentierung |
| Observability | Metrik-Instrumentierung | [-@sec:ms-principle7;-@sec:monitoring] | White-Box Instrumentierung |
| Observability | Tracing-Instrumentierung | [-@sec:ms-principle7;-@sec:tracing] | White-Box Instrumentierung |
| Service Mesh | Sidecar-Proxy | [-@sec:ms-principle7;-@sec:service-meshs] | Black-Box Instrumentierung |
| Service Mesh | Quantitatives Traffic Splitting | [-@sec:traffic-management] | für Canary Releases |
| Service Mesh | Inhaltsbasiertes Traffic Splitting | [-@sec:traffic-management] | für Blue/Green oder A/B Releases |
| Service Mesh | Resilienzkonfiguration | [-@sec:ms-principle6;-@sec:circuit-breaker;-@sec:bulkhead;-@sec:resilienz] | Timeout-, Retry-, Circuit-Breaker-Settings |
| Service Mesh | Visualisierung von Verkehrstopologien | [-@sec:ms-principle7;-@sec:verkehrstopologien] | Birds-Eye View |
| Problemraum | Core Domain | [-@sec:ddd-strategisches-design;-@sec:core-domain] | DDD-Strategic Design |
| Problemraum | Supporting Domain | [-@sec:ddd-strategisches-design;-@sec:supporting-domain] | DDD-Strategic Design |
| Problemraum | Generic Domain | [-@sec:ddd-strategisches-design;-@-@sec:generic-domain] | DDD-Strategic Design |
| Problemraum | Ubiquitous Language | [-@sec:ddd-strategisches-design;-@sec:ddd-fachlichkeit;-@sec:ubiquitous-language] | DDD-Strategic Design |
| Problemraum | Bounded Context | [-@sec:ddd-strategisches-design;-@sec:ddd-bounded-contexts] | DDD-Strategic Design |
| Context Map | Partnership | [-@sec:context-mapping;-@sec:kooperation;-@sec:context-maps] | DDD-Strategic Design |
| Context Map | Shared Kernel | [-@sec:context-mapping;-@sec:kooperation;-@sec:context-maps] | DDD-Strategic Design |
| Context Map | Conformist | [-@sec:customer-supplier;-@sec:context-maps] | DDD-Strategic Design |
| Context Map | Open Host System (OHS) | [-@sec:customer-supplier;-@sec:context-maps] | DDD-Strategic Design |
| Context Map | Anti-Corruption-Layer (ACL) | [-@sec:customer-supplier;-@sec:context-maps] | DDD-Strategic Design |
| Context Map | Separate Ways | [-@sec:separate-ways;-@sec:context-maps] | DDD-Strategic Design |
| Lösungsraum | Extract-Transform-Load | [-@sec:ddd-taktisches-design;-@sec:etl-pattern] | DDD-Tactical Design für Supporting Domains |
| Lösungsraum | Active Record | [-@sec:ddd-taktisches-design;-@sec:active-record] | DDD-Tactical Logik-Design für Supporting Domains |
| Lösungsraum | Domain Model | [-@sec:ms-principle1;-@sec:ddd-taktisches-design;-@sec:domain-model] | DDD-Tactical Logik-Design für Core Domains |
| Lösungsraum | Event Sourcing | [-@sec:ddd-taktisches-design;-@sec:event-sourcing] | DDD-Tactical Logik-Design für Core Domains |
| Lösungsraum | Layered Architecture | [-@sec:ddd-taktisches-design;-@sec:ddd-layered-architecture] | DDD-Tactical Architektur-Design für Supporting Domains |
| Lösungsraum | Ports+Adaptor Architecture | [-@sec:ddd-taktisches-design;-@sec:ddd-ports-adapters] | DDD-Tactical Architektur-Design für Core Domains |
| Lösungsraum | CQRS Architecture | [-@sec:cna-definition;-@sec:scaling-state;-@sec:scaling-with-cqrs;-@sec:ddd-taktisches-design;-@sec:ddd-cqrs] | DDD-Tactical Architektur-Design für Core Domains |