Domain-Driven Transformation Monolithen und Microservices zukunftsfähig machen /

In den letzten Jahrzehnten wurde viel Software entwickelt, die wir heute modernisieren und zukunftsfähig machen müssen. Carola Lilienthal und Henning Schwentner haben in den vergangenen Jahren umfassende Erfahrungen gesammelt, wie sich Domain-Driven Design (DDD) einsetzen lässt, um große Legacy-...

Descripción completa

Detalles Bibliográficos
Clasificación:Libro Electrónico
Autores principales: Lilienthal, Carola (Autor), Schwentner, Henning (Autor)
Formato: Electrónico eBook
Idioma:Alemán
Publicado: Heidelberg : dpunkt.verlag, 2023.
Temas:
Software architecture.
Software engineering.
Architecture logicielle.
Génie logiciel.
Electronic books.
Acceso en línea:Texto completo (Requiere registro previo con correo institucional)
Tabla de Contenidos:
  • Domain-Driven Transformation
  • Vorwort
  • Inhaltsübersicht
  • Inhalt
  • 1 Einleitung: Komplexität beherrschen
  • 1.1 Komplexität
  • 1.2 Herkunft der Komplexität: Problem- und Lösungsraum
  • 1.3 Art der Komplexität: essenziell vs. akzidentell
  • 1.3.1 Quellen akzidenteller Komplexität
  • 1.3.2 Entscheidungsbereiche von Softwarearchitektur
  • 1.4 Komplexität in Legacy-Systemen
  • 1.5 Struktur dieses Buches
  • Teil I
  • Grundlagen für Domain-Driven Transformation
  • Die grundlegenden Methoden
  • Komplexität sichtbar machen mit Architekturdokumentation
  • Das C4 Model
  • Wie weiter?
  • 2 Domain-Driven Design
  • 2.1 DDD-Konzepte gegen Komplexität
  • 2.2 DDD und die Fachdomäne
  • 2.2.1 Ubiquitous Language
  • 2.2.1.1 Begri smodelle
  • 2.2.1.2 Glossare
  • 2.2.1.3 Verschmutzung der Fachsprache mit technischen Begri en
  • 2.2.1.4 Deutsch oder Englisch?
  • 2.2.2 Strategisches Design in der Domäne
  • 2.2.3 Subdomänen kategorisieren
  • was ist der Kern?
  • 2.2.3.1 Core Domain
  • 2.2.3.2 Generic und Supporting Subdomain
  • 2.3 DDD und die Softwarelösung
  • 2.3.1 Strategisches Design in der Technik
  • 2.3.1.1 Bounded Context
  • 2.3.1.2 Context Map
  • 2.3.2 Context Mapping
  • 2.3.2.1 Dimension »Zusammenarbeit zwischen den Teams«
  • 2.3.2.2 Dimension »Technische Umsetzung der Schnittstelle«
  • 2.3.3 Bubble Context
  • 2.3.4 Das Domänenmodell
  • 2.3.4.1 Domänenmodell im Kontext
  • 2.3.4.2 Wiederverwendung, Duplikation und Redundanz
  • 2.3.5 Die Schichtenarchitektur in DDD
  • 2.3.6 Taktisches Design
  • 2.3.7 Domain Events
  • 2.4 Zusammenfassung
  • 3 Collaborative Modeling
  • 3.1 Die richtigen Leute zusammenbringen
  • 3.2 Grundlegende Konzepte des Collaborative Modeling
  • 3.3 Modellierungswerkzeuge und das Modellmonopol
  • 3.4 Collaborative Modeling und DDD
  • 3.5 Domain Storytelling
  • 3.5.1 Ein Bild - eine Geschichte
  • 3.5.2 Grenzen ziehen
  • 3.5.3 Scope-Faktoren für Domain Stories
  • 3.5.4 Das Domänenmodell nden
  • 3.5.5 Ausblick
  • 3.6 Event Storming
  • 3.6.1 Storming-Phase
  • 3.6.2 Zeitliche Ordnung herstellen
  • 3.6.3 Grenzen ziehen
  • 3.6.4 Die Farbcodierung
  • 3.6.5 Tiefer ins Detail: Design Level Event Storming
  • 3.6.6 Das Domänenmodell nden
  • 3.6.7 Weitere Formate und Ausblick
  • 3.7 Wann welche Methode einsetzen?
  • 3.8 Collaborative Modeling Remote
  • 3.9 Andere Techniken des Collaborative Modeling
  • 3.10 Zusammenfassung
  • 4 Architekturkonzepte
  • 4.1 Modularität
  • 4.2 Kohäsion und Kopplung
  • 4.2.1 Kohäsion und Kopplung in der Fachlichkeit
  • 4.3 Big Ball of Mud
  • 4.3.1 Auf Klassenebene
  • 4.3.2 Auf Architekturebene
  • 4.3.3 Entstehen eines Big Ball of Mud
  • 4.3.4 Kopplung und Wiederverwendung
  • 4.4 Monolith
  • 4.5 Microservices
  • 4.6 Vom Monolithen zu Microservices
  • 4.7 Die gute alte Schichtenarchitektur
  • 4.8 Hexagonal Architecture und ihre Varianten: Onion, Clean und mehr
  • 4.8.1 Verschiedene Stile zusammen
  • Explicit Architecture
  • 4.8.2 Innen-außen-Architekturen und taktisches DDD

Ejemplares similares