Lehr- und Ausbildungspläne für Softwarearchitekten (Certified Professional for Software Architecture) Definition von Zertifizierungsprüfungen auf Basis der CPSA-Lehrpläne Sicherstellung der fachlich- inhaltlichen Qualität von Lehre, Aus- und Weiterbildung für Softwarearchitektur iSAQB? Internation al Software Architectur e Qualificati on Board e.V.
• Vertiefung des Foundation Levels. • Der Lehrplan besteht aus einzelnen Modulen, die bestimmte Schwerpunkte haben. Advanced Level • Aufgaben, Methoden und Techniken für die Entwicklung von Softwarearchitekturen. • Alle Aspekte, die für Softwarearchitektur wesentlich sind. Technologische, organisatorische und soziale Faktoren. Foundation Level iSAQB-Zertifizierungsstufen
Architekturaufgaben, unabhängig von Technologien. Technische Kompetenz: Kenntnis und Anwendung von Technologien zur Lösung von Entwurfsaufgaben. Kommunikative Kompetenz: Fähigkeiten zur produktiven Zusammenarbeit mit unterschiedlichen Stakeholdern, Kommunikation, Präsentation, Argumentation, Moderation. à Alle drei Kompetenzbereiche müssen abgedeckt sein (mindestens 10 Credit Points pro Kompetenzbereich) à Insgesamt sind 70 Credit Points erforderlich à 10 Credit Points entsprechen in der Regel einem Schulungstag à Eine Schulung zu einem Lehrplanmodul bringt maximal 30 Credit Points, auch wenn sie länger als 3 Tage ist à Es ist möglich sich bestimmte andere Zertifikate anerkennen zu lassen Kompetenzbereiche Advanced Level
als CPSA-A geprüft werden möchten, müssen Sie sich bei einer der anerkannten Zertifizierungsstellen anmelden. Die Zertifizierungsstelle schickt Ihnen in Absprache eine Prüfungsaufgabe zu, die Sie in etwa 40 Arbeitsstunden lösen und deren Lösung Sie dokumentieren müssen. Sie schicken die Lösung an die Zertifizierungsstelle ein. Die Zertifizierungsstelle bestellt zwei unabhängige Prüfer und übergibt ihnen Ihre Lösung, so dass sie begutachtet werden kann. Die Prüfer telefonieren anschließend noch mit Ihnen als Teilnehmer. Sie müssen Ihre Lösung in diesem Gespräch erklären und verteidigen. Wenn die Prüfer bestätigen, dass Sie alle Voraussetzungen für den CPSA-A erfüllen, dass Ihre Lösung gut ist und dass Sie die Lösung gut dokumentiert, erklärt und verteidigt haben, stellt Ihnen die Zertifizierungsstelle das CPSA-A Zertifikat aus. Prüfung iSAQB Advanced Level
Kommunikation 10 Softwaresysteme und -architekturen nach agilen Prinzipien entwerfen und weiterentwickeln Agile Prinzipien und Ideen auf Architekturarbeit übertragen Architekturpraktiken sinnvoll in agiles Vorgehen verankern Arbeiten in selbstorganisierte Teams und gemeinsam wahrgenommene Verantwortung erfordern neue Fähigkeiten, sowohl technischer als auch methodischer und kommunikativer Art. Diese werden theoretisch und praktisch behandelt. à https://www.wps.de/schulungen/isaqb/agila
Methodik 20 Softwarearchitekturen anhand ökonomischer und technischer Ziele systematisch verbessern Grundlagen von Evolution und Verbesserung von Softwarearchitekturen Ist-Situation analysieren Probleme und Lösungsansätze schätzen und bewerten Verbesserung langfristig planen Typische Ansätze und Beispiele für Verbesserung à https://www.wps.de/schulungen/isaqb/improve
| Kommunikation 10 Passgenaue Softwarearchitekturen durch Kommunikation mit den Fachexperten und einheitliche Konstruktionsbausteine entwickeln Eine gemeinsame Sprache erleichtert die Zusammenarbeit Software nach fachlichen Gesichtspunkten strukturieren Kommunikation ist der Schlüssel – miteinander und zwischen Teams Bausteine von DDD geben team-übergreifende Anleitungen für die Konstruktion à https://www.wps.de/schulungen/isaqb/ddd
Methodik 10 Flexible Architekturkonzepte und Methoden, um Software schnell und mit hoher Qualität in die Produktion zu bringen: Microservices entwerfen DevOps und Continuous Delivery umsetzen Containerisierung Resiliente Systeme betreiben à https://www.wps.de/schulungen/isaqb/flex
Methodik 10 Architekturkonzepte und Methoden, um Software in der Cloud sicher und flexibel zu betreiben und das Skalierungspotential auszuschöpfen: Microservices verstehen Cloudangebote und deren Anwendung Containerisierung und Container-Manager einsetzen Resiliente Systeme betreiben à https://www.wps.de/schulungen/isaqb/cloudinfra Selbstbedienung nach Bedarf Erreichbar per Internet Ressourcen-Pool für mehrere Kunden Service wird gemessen bzw. überwacht Hohe Elastizität Microservices Containers Platforms Cloud Infrastructure
Methodik 10 Sicherheit in Analyse– und Entwicklungsprozesse integrieren mit Fokus auf Webapplikationen Basiswissen und Begriffe: Was ist „Security“? Analyse von Schutzbedarf und Angriffsvektoren Kryptografische Grundlagen Übliche Schwachstellen von Webapplikation und Gegenmaßnahmen à https://www.wps.de/schulungen/isaqb/websec
PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN BERECHNET 3 E R Z E UG T 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN
PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN BERECHNET 3 E R Z E UG T 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN
PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN BERECHNET 3 E R Z E UG T 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN TIEFEN- MESSUNG MANÖVER- PLANUNG MANÖVER- PLANUNG TIEFEN- MESSUNG
(VERMEINTLICH) TECHNISCHE PROBLEME § „Wollen (Micro)Services bauen und suchen Hilfe beim Schneiden der Services.“ § „Sind mit technisch geschnittenen Services auf die Nase gefallen“ § „Haben Wartung übernommen, verstehen das System nicht!“ § „Monolith ist zu komplex, wie können wir ihn modularisieren?“ § „Teile der Anwendung skalieren nicht mehr. Wie lösen wir das aus dem Monolithen raus?“
ORGANISATORISCHE PROBLEME § „Nach raschem Wachstum der Software und des Teams brauchen wir tragfähige Strukturen“ § „Teams stehen sich gegenseitig auf den Füßen und arbeiten nicht mehr effizient“
höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Wir heißen Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. […] https://agilemanifesto.org/principles.html DOMÄNE KENNEN- L ER NEN AUF- TEIL EN SPRACHE MODELL CODE
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. […] https://agilemanifesto.org/principles.html „Es gibt nur eine Definition of Done: Den Roundhouse Kick!“ Chuck Norris
uns fachlich EIN STÜCK WEITER gebracht hat. PEIL- POSITION ERREICHT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT
TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNET ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETTE DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETTE AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETTE 300M VER- SCHOBEN M SIM
TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNET ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETTE DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETTE AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETTE 300M VER- SCHOBEN M SIM
TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNET ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETTE DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETTE AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETTE 300M VER- SCHOBEN M SIM STURMFLUT ERWARTET ALLE LIEGE- PLÄTZE BELEGT PEILSCHIFF AUF GRUND GELAUFEN
TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNET ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETTE DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETTE AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETTE 300M VER- SCHOBEN M SIM BEI WELCHEN TIEFEN? HIER PASSAGE BERÜCK- SICHTI- GEN!
In die Nähe des betroffenen Events hängen! HOTSPOT PEIL- POSITION ERREICHT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT BEI WELCHEN TIEFEN?
TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNET ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETTE DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETTE AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETTE 300M VER- SCHOBEN M SIM STURMFLUT ERWARTET ALLE LIEGE- PLÄTZE BELEGT PEILSCHIFF AUF GRUND GELAUFEN BEI WELCHEN TIEFEN? HIER PASSAGE BERÜCK- SICHTI- GEN!
EVENT STORMING MUSTERSPRACHE AGGREGATE COMMAND ACTOR Tag 3 Taktisches Design Tag 1 Big Picture invoked on translated into generates invoked on generates triggers invokes invokes observed by
Schneiden der Domäne mit Subdomains § Die Welt verstehen § Unterteilungen finden § Core, Supporting, und Generic Subdomains § Modellbildung mit Bounded Contexts § Beziehungen erfassen mit Context Maps à Strategisches Design – Design im Großen
Hirn ist zu klein, um die Welt im Ganzen zu begreifen § Deshalb bauen wir uns Modelle ØWir abstrahieren ØWesentliches behalten ØUnwesentliches weglassen WIE KÖNNEN WIR DIE WELT VERSTEHEN? ? Foto: Maiconfz/pixabay/ CC0 Foto: Wikipedia/CC-PD
/ KLEINE MODELLE Foto: Maiconfz/pixabay/CCO Foto: Globus from book shelf/wikipedia/ CC-BY-3.0 Foto:Clker-Free-Vector-Images/pixabay/ CCO Foto: Wasserseemüller-Globus/Wikipedia/CC-PD-Mark
a genius, but not because of the superior computational power of his brain. Newton's genius was, on the contrary, his ability to simplify, idealize, and streamline the world so that it became, in some measure, tractable to the brains of perfectly ordinary men.” – Jerry Weinberg ISAAC NEWTON AND MODELS
WIR DIE DOMÄNE VERSTEHEN / IN SOFTWARE GIEßEN? ? § Klassischer Ansatz: § Ein Stück Software, das die Domäne im Ganzen modelliert und möglichst detailgenau abbildet § Hoffnung: § Probleme werden einmal und für alle Zeiten gelöst § Keine Duplikation
Domäne kann in Subdomänen aufgeteilt werden èKeine Vermischung! èKein big ball of mud § Arten von Subdomänen § Kern (Core Subdomain) § Unterstützende (Supporting Subdomain) § Allgemeine (Generic Subdomain) STRATEGISCHES DESIGN
Domäne ist zu komplex für Verständnis im Ganzen § Mehrere kleinere Modelle entwickeln § Mehrere Stücke Software bauen – eines pro Modell WIE KÖNNEN WIR DIE DOMÄNE VERSTEHEN / IN SOFTWARE GIEßEN? ?
Grenzen im Prozess § Statusänderungen, die das »Wesen« eines Arbeitsgegenstandes verändern (z.B.: § »Vertrag rechtskräftig«, § »Warenkorb bestellt«) § Abteilungen in der Organisation § Kontextuelle Sprache § Unterschiedlicher Umgang mit den Arbeitsgegenständen § Unterschiedliche zeitliche Trigger § NICHT: Nach Arbeitsgegenständen selbst! WIE SCHNEIDE ICH MEINE DOMÄNE?
POINTS OF NO RETURN! PEIL- POSITION ERREICHT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN M SIM
POINTS OF NO RETURN! PEIL- POSITION ERREICHT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN M SIM
POINTS OF NO RETURN! PEIL- POSITION ERREICHT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN M SIM
POINTS OF NO RETURN! PEIL- POSITION ERREICHT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN M SIM
SUBDOMÄNEN ON HT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S
SUBDOMÄNEN ON HT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S
SUBDOMÄNEN ON HT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S BOUNDARY
SUBDOMÄNEN ON HT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S BOUNDARY EVENT
SUBDOMÄNEN ON HT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S VORBEREITUNG MANÖVER- PLANUNG
SUBDOMÄNEN ON HT TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S VORBEREITUNG MANÖVER- PLANUNG
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S VORBEREITUNG MANÖVER- PLANUNG
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- MESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- MESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE Ist die berechnete Zoomstufe für die Tidevorhersage relevant?
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- MESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE Die Manöverplanung benötigt die berechnete Zoomstufe!
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET EFE AN DIENST MELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG N- NG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET EFE AN DIENST MELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG N- NG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE Die Tidevorhersage beginnt »spontan«, ohne auslösendes Event von außen!
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET EFE AN DIENST MELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG N- NG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SUBDOMÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET EFE AN DIENST MELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG N- NG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SUBDOMÄNEN TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- ESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SUBDOMÄNEN TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- ESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SUBDOMÄNEN TIEFE »10M« GEPEILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFEN BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- ESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SUBDOMAINS § Ausdrücken, was geschieht: Was ist die Mission der Subdomäne? § Substantivierte Verben § Häufig: -ung-Formen PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- MESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE PEILPLAN ERSTELLT Pro-Tipp: Schaue auf das ERGEBNIS des Teilprozesses!
PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN BERECHNET 3 E R Z E UG T 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN
DOMAIN STORIES FINDEN § Bleibe in grobgranularen Stories § Gruppiere die Schritte § Zeichne Grenzen um Aktivitäten und Arbeitsgegenstände § Lasse Akteure außerhalb dieser Grenzen § Passe ggf. das Layout der Stories an die neuen Grenzen an § Beachte Indikatoren (Prozessgrenzen, Statusänderungen, Sprache, usw.) § Nutze »pure« Domain Stories § Fokussiere auf den Papierprozess (rein fachliches Vorgehen, nicht digitalisiert) § Füge virtuelle Akteure hinzu
PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN BERECHNET 3 E R Z E UG T 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN TIEFEN- MESSUNG Gruppiere die Schritte • Grenze um Aktivitäten und Arbeitsgegenstände • Akteure bleiben außerhalb Benenne die Gruppen
§ Teil der Geschäftsdomäne § Von entscheidender Wichtigkeit für den Unternehmenserfolg èHier muss die Firma sich hervorheben èDieses Projekt sollte die höchste Priorität bekommen èDas Softwaresystem, das die Kerndomäne repräsentiert, ist ein Wettbewerbsvorteil, kein notwendiges Übel. èUSP (Unique Selling Point) Grafik: Core by Virginie Angéloz from the Noun Project
Subdomain § Modelliert einen Aspekt, der entscheidend ist, aber nicht Teil des Kerns § Teilweise spezialisiert für das Geschäft § Generic Subdomain § Nicht spezialisiert § Notwendig für die Gesamtlösung èNicht unwichtig! èKein Bedarf hier exzellent zu sein SUPPORTING UND GENERIC SUBDOMAIN Foto:Customer support/Sharique.m3em/Wikipedia/CC-BY-SA-4.0
Das allumfassende Modell kann oft nicht gebaut werden § Komplexität § Kosten § Die Domäne zerfällt in Subdomains § Subdomains sind unterschiedlich wichtig § Die Core Domain ist am wichtigsten § Supporting und Generic Subdomains unterstützen
Schneiden der Domäne mit Subdomains § Modellbildung mit Bounded Contexts § Problem- versus Lösungsraum § Horizontale vs. vertikale Schichtung § Brownfield Strategic Design § Beziehungen erfassen mit Context Maps à Strategisches Design – Design im Großen
LÖSUNGSRAUM (PROBLEM SPACE vs SOLUTIONS SPACE) § Problemraum: § Ermöglicht uns, über die geschäftlichen Herausforderungen nachzudenken § Hier befinden wir uns nur in der Fachlichkeit § Besteht aus 1 – n Subdomänen § Lösungsraum: § Konzentriert darauf, wofür und wie wir Software implementieren, die das Problem löst § Hier gibt es auch Technik § Besteht aus 1 – n Bounded Contexts § Je ein subdomänenspezifisches Softwaremodelle Foto: gerat/pixabay/CC0
PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN BERECHNET 3 E R Z E UG T 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN TIEFEN- MESSUNG MANÖVER- PLANUNG MANÖVER- PLANUNG PEILPLAN- ERSTELLUNG TIEFENMESSUNG
§ Jedes Modell hat einen Kontext § Kontext = Grundsätzliche Voraussetzungen, damit Begriffe eine bestimmte Bedeutung erhalten § Wird ein Modell aufgespalten, so ist für jedes Teilmodell eine Kontextdefinition erforderlich § Setze explizite Grenzen in § Teamorganisation § Code/Modulen § Datenbank-Schemata § (Quellcodeverwaltung) § (Deployment-Einheiten)
ÜNSCHT SICH 1 VERKÄUFER UNTERSCHREIBT VON HÄNDIG T AUS FÜR VERTRAG 3 RISIKOMANAG ER VERTRAG GIBT WEITER AN 4 VERTRAG V O T IER T PRÜFT B ER EC HN ET 5 6 7 KALKU- LIERT A N 8 2 AUTO BONITÄT LEASING- RATE AUTO WIEDERVER- KAUFSWERT VERTRAG
ÜNSCHT SICH 1 VERKÄUFER UNTERSCHREIBT VON HÄNDIG T AUS FÜR VERTRAG 3 RISIKOMANAG ER VERTRAG GIBT WEITER AN 4 VERTRAG V O T IER T PRÜFT B ER EC HN ET 5 6 7 KALKU- LIERT A N 8 2 AUTO BONITÄT LEASING- RATE AUTO WIEDERVER- KAUFSWERT VERTRAG VERTRIEB RISIKOBEWERTU NG VERTRIEB RISIKOBEWERTU NG
Grenzen im Prozess § Statusänderungen, die das »Wesen« eines Arbeitsgegenstandes verändern (z.B.: § »Vertrag rechtskräftig«, § »Warenkorb bestellt«) § Abteilungen in der Organisation § Kontextuelle Sprache § Unterschiedlicher Umgang mit den Arbeitsgegenständen § Unterschiedliche zeitliche Trigger § NICHT: Nach Arbeitsgegenständen selbst! WIE SCHNEIDE ICH MEINE DOMÄNE? – REVISITED
Teil der Domäne § Fachliche Einteilung § Schon da § Problemraum Bounded Contexts: § Teil des Designs / der Modellbildung § Technische Einteilung § Wird gebaut § Lösungsraum SUBDOMAINS VS BOUNDED CONTEXTS
CONTEXT / SUBDOMAIN § In einem Projekt, das auf der grünen Wiese nach DDD gebaut wurde (Greenfield) haben wir eine 1:1-Abbildung von BC und Subdomain § In der Startphase eines Projektes wird ein BC eine Subdomäne nur zum Teil abdecken § In späteren Phasen ist oft ein Mismatch vorhanden (Brownfield), z.B.: § 1 System für n Probleme § n Systeme für 1 Problem § überlappende / doppelte / fehlende Verantwortlichkeiten § Legacy-Systeme sind oft »Unbounded Contexts« Zwei Seiten einer Medaille Foto: Dreibund Medaille/Wikipedia/CC BY-SA 3.0
SUBDOMAINS / ABTEILUNGEN VS. BOUNDED CONTEXTS Lohnbuch- haltung Personal- wesen proALPHA ERP Banksystem § Ziel: Eins-zu-eins-Abbildung § In brownfield-Situation oft nicht möglich. § Manchmal auch im Greenfield nicht möglich, z.B. weil: § Standardsoftware eingesetzt wird § Technische Gründe Subdomain Context / (Dritt-)System Vertrieb Vertrieb
NEGATIV-BEISPIEL: fachlich vs. technisch vs. organisatorisch CORE MASTER BI VERKAU F FAKTU RA VERSAND ARTIKEL- AUSWAHL TEAM BESTAND TEAM BI TEAM SALE TEA M LO G ISTIK
NEGATIV-BEISPIEL: fachlich vs. technisch vs. organisatorisch CORE MASTER BI VERKAU F FAKTU RA VERSAND ARTIKEL- AUSWAHL TEAM BESTAND TEAM BI TEAM SALE TEA M LO G ISTIK An den Brüchen entstehen »Schmerzen«! • fachlich • technisch • organisatorisch Und kompliziert ist es auch noch! BIG BALL OF PAIN
POSITIV-BEISPIEL: fachlich vs. technisch vs. organisatorisch TEA M V ERKAU F TEA M FA KTU RA TEAM VERSAND TEAM ARTIKEL- AUSWAHL Es bleibt zusammen, was zusammen gehört! • fachlich • technisch • organisatorisch Und es ist so einfach! Beinahe trivial.
NEGATIV-BEISPIEL: fachlich vs. technisch vs. organisatorisch CORE MASTER BI VERKAU F FAKTU RA VERSAND ARTIKEL- AUSWAHL TEAM BESTAND TEAM BI TEAM SALE TEA M LO G ISTIK TEA M V ERKAU F TEA M FA KTU RA TEAM VERSAND TEAM ARTIKEL- AUSWAHL
CONTEXT KANN EIN EIGENES TEAM HABEN § Teams entwickeln unabhängig voneinander § Jedes Team hat eine Zuständigkeit / ist Besitzer eines Modells § Jedes Team vereint fachliches und technisches Wissen (cross-functional)
BEISPIEL 1 VERTIKAL: fachlich HORIZONTAL: technisch ARTIKEL- AUSWAHL VERKAUF FAKTURA VERSAND UI APPLICATION DOMAIN DATABASE TEAM ARTIKEL- AUSWAHL TEAM VERKAUF TEAM VERSAND TEAM FAKTURA
BEISPIEL 1 VERTIKAL: fachlich HORIZONTAL: technisch ARTIKEL- AUSWAHL VERKAUF FAKTURA VERSAND UI APPLICATION DOMAIN DATABASE TEAM ARTIKEL- AUSWAHL TEAM VERKAUF TEAM VERSAND TEAM FAKTURA
SOZIO-TECHNISCHES SYSTEM “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin E. Conway, How Do Committees Invent? Melvin Conway
SOCIO-TECHNICAL SYSTEM II “The organization of the software and the organization of the software team will be congruent.” Eric S. Raymond “If you have four groups working on a compiler, you'll get a 4-pass compiler.”
Die Domäne hat einen Lösungs- und einen Problemraum § Große Projekte werden auf mehrere Teams aufgeteilt § Ein Domänenmodell muss konsistent sein § Definiere einen Bounded Context für jedes Modell § Klare Grenzen § Bounded Contexts kommunizieren oft über Domain Events § Auch im Brownfield ist strategisches Design möglich
Schneiden der Domäne mit Subdomains § Modellbildung mit Bounded Contexts § Beziehungen erfassen mit Context Maps § Beziehungen zwischen Bounded Contexts § Beziehungen zwischen Teams § Integration von Bounded Contexts zu Gesamtsystem à Strategisches Design – Design im Großen Lewin Fidel David Amon
§ Wir haben die Domäne mit Bounded Contexts zerteilt, aber die Teile sind nicht völlig unabhängig voneinander! § Welche Beziehungen gibt es zwischen den Teams / Contexten? § Mit welchen Integrationsmustern werden sie implementiert? § Eine Context Map zeigt in einem Diagramm: § Alle Bounded Contexts § Und ihre gegenseitigen Abhängigkeiten
§ Wenn es keinen fachlichen Grund gibt, zwei Bounded Contexts zu integrieren, d.h. sie sind wirklich unabhängig voreinander § Oder wenn es zwar einen Grund gibt, aber die Integration zweier Bounded Contexts nicht genug Nutzen verspricht à jedes Team geht seinen eigenen Weg. Evtl. ab und zu manuelle Übertragung einiger Daten durch Nutzer. § Oder, wenn es explizit verboten ist, dass zwei Contexte direkt interagieren Foto: GiselaFotografie, Pixabay License A B C X
Die Teams einigen sich gemeinsam auf Schnittstelle / Modell § Gemeinsames Ziel / voneinander abhängige Ziele § Teams können nur gemeinsam Erfolg haben à wenig Autonomie § Hoher Abstimmungsaufwand § Viele Meetings § Gemeinsames Deployment § Unterstützung bei Features, Integration, Test § Gemeinsames (Teil-)Modell § Private Schnittstelle à Auf Dauer ist dies eher ein Anti-Pattern à Wir streben unabhängigere Teams an Foto: Wikipedia/flickr/CC-BY Ryan C
BEZIEHUNGEN ZWISCHEN TEAMS Einige Mapping-Typen unterscheiden zwischen Upstream und Downstream: § Ein Team liefert für ein anderes § Upstream-Team: Setzt eine Fachlichkeit um § Downstream-Team: Setzt darauf auf § Datenfluss vs. Modelhoheit àDatenfluss ist üblicherweise trivial àInteressanter ist: Welches Teams spezifiziert das gemeinsame Modell, das für die inter-context Kommunikation zuständig ist? Foto: benralexander/pixabay/CC0
Das Upstream-Team stellt einen Dienst / ein Modell bereit § Downstream-Team übernimmt dieses unverändert (1:1) § D. h. übernimmt auch Teil der Ubiquitous Language von Upstream § Downstream-Team hat keinen Einfluss auf Upstream-Team Foto: Staff Sgt. D. Myles Cullen/Wikipedia/PD US Air Force
(ACL) § Das Gegenteil von Conformist – d. h. defensive Integration § Downstream-Team übersetzt zwischen eigenem Modell und dem des Upstream-Teams § Bei Änderungen im Upstream-Modell muss nur ACL angepasst werden § ACL kann z. B. als Adapter einer Ports & Adapter-Architektur implementiert Domain Model Bounded Context (downstream) ACL kennt Upstream Daten- modell kennt stellt bereit
Bounded Context (upstream): § definiert ein Protokoll/API § zum Zugriff auf sein Modell (i. d. R. vereinfachtes Modell an der Schnittstelle) § als eine Menge von Services § für mehrere, ihm unbekannte, Consumer § Offen, weil jeder das Protokoll verwenden kann § Die entstehende API ist wohldefiniert und –dokumentiert Quelle: edwardpye/pixabay/CC0
§ Eine gut dokumentierte Sprache zum Informationsaustausch § Kann definiert werden in § XML Schema § JSON Schema § Protobuf § usw. § Oft »spricht« ein Open-Host-Service eine PL § Beispiele: § SEPA-XML für Überweisungen und Mandate § BIPRO für Versicherungen § HL7 FHIR für Gesundheitswesen § WMS für Kartendaten Quelle: Merker Berlin/Wikipedia/PD-self
§ Bounded Contexts enthalten ein kleines, gemeinsam genutztes Teilmodell, den Shared Kernel. § Wird dieser Shared Kernel weiterentwickelt, werden alle beteiligten Teams mit einbezogen. § Die Kontexte der Teams bleiben weiterhin voneinander abgegrenzt. § Shared Kernel bedeutet: Beziehung auf Team-Ebene und auf Code-Ebene. § Kandidaten für Shared Kernel sind z. B. Standards wie ICD-10 (medizinische Diagnosen) Foto: Sander van der Wel/Wikipedia/CC BY-SA 2.0
OF MUD § Das Context-Mapping Anti-Pattern § Oft bei Altsystemen anzutreffen § Keine saubere Aufteilung in Bounded Contexts Foto: Benutzer:Summi/Wikipedia/CC-BY-SA-3.0-migrated
HAFEN-BEISPIEL TIDE- VORHER- SAGE MANÖVER- PLANUNG TIEFEN- MESSUNG PEILPLAN- ERSTELLUNG ZOOMSTUFEN- BERECHNUNG REST CSV- IMPORT REST RPC OHS + PL O H S ACL CON FORM IST CUST SUPP
Context Maps zeigen Bounded Contexts und ihre Beziehungen § Sie sollen: § Team-übergreifende Kommunikation unterstützen (z. B. wenn es um Kontextübergreifende Anforderungen geht) § »project thinking« der Teams ermöglichen § Integrationsbedarf erkennen und passende Integrationsformen erkennen § Einige Context Mapping Patterns können miteinander kombiniert werden
Auf den Feature Branch pushen? Den Container hochfahren Ich baue dafür ein Interface Foto: Boboss74/deviantart Foto: Cronoxyd/Wikipedia/CC BY-SA 3.0 Foto: Microsoft/Wikipedia/PD ineligible
BEISPIEL SCHACH Brett König Figuren Spieler Schachuhr Foto: Fotograf Frank Hoppe/ Garry Kasparov/Wikipedia/PD-self Foto: Wikipedia/PD shape Foto: Thomas Depenbusch (Depi)/flickr/CC BY 2.0 Foto: Wikipedia/CC BY-SA 3.0 Foto: Wikipedia/CC BY-SA 3.0
sprache } UBIQUITOUS LANGUAGE public class Peilplan { public void zieheTiefenlinien() { /* ... */ } public void faerbeTiefenzahlen() { /* ... */ } } Fach- sprache
§ Fachexperten verstehen keine Begriffe zu technischen Umsetzungen § Fachexperten sprechen den Jargon ihrer Domäne, der für Außenstehende wiederum schwer verständlich sein kann è Eine gemeinsame Sprache ist notwendig! § Welche soll es sein? § Die der Entwickler? § Die der Fachexperten? § Etwas dazwischen? èPrinzip von DDD: »Verwende eine Sprache die auf dem Domänenmodell basiert« Foto: The Tower of Babel/Pieter Brueghel the Elder/Wikipedia/CC-PD-Mark
PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN BERECHNET 3 ERZ EU G T 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN
sind drei gute Beispiele besser für das Verständnis der Anforderungen als eine schlechte Abstraktion.« -- Peter Hruschka in Busines Analysis und Requirements Engineering, S.102, Hanser, 2014
§ Grobgranular: § Einstieg/Überblick über die Domäne § Subdomänen und Bounded Contexts finden § Projektumfang abgrenzen § Feingranular: § Implementierbares Domain Model § Arbeitsabläufe analysieren oder gestalten Zeitpunkt § Ist: Problemraum analysieren § Soll: Lösungsraum gestalten § Verschiedene Soll-Zeitpunkte sind möglich (Soll in 6 Monaten, in 2 Jahren, …) Domain Purity: § Prozess mit heutiger oder zukünftiger Software- Unterstützung § Prozess ohne Software modellieren: § Reine Fachlichkeit § Befreit den Prozess von technischen Begriffen
& Co sind mit Vorsicht zu genießen: § Von Software-Entwicklern für Software- Entwickler § Für Workshops bedingt geeignet à Gefahr, dem Kunden ungewollte eine abstrakte IT-Sicht aufzudrängen § Schwerpunkt auf Dokumentation statt auf Kommunikation DIE UBIQUITOUS LANGUAGE ENTWICKELN Fach- sprache Techno Babble ?
Für Kernkonzepte (weil viel Arbeit) § bereits existierende Begriffe § rekonstruierte Begriffe § neue Begriffsbildungen § Wichtiger am Anfang des Projektes und für neue Mitarbeiter § Oft Wegwerfprodukt (nicht mehr gepflegt) § Ein Wörterbuch ersetzt keinen Sprachkurs! Woher kommen die Wörter fürs Glossar? Foto: George Eastman Museum/Wikipedia
BEISPIELDOMÄNE SCHACH SPIELER EINE VON ZWEI PERSONEN, DIE FIGUREN AUF DEM BRETT BEWEGT. SPRINGER (PFERD) EINE FIGUR, VON DER JEDER SPIELER ZWEI BESITZT. WIRD ZWEI FELDER VOR UND EINES ZUR SEITE BEWEGT. SPRINGT BEIM VORZIEHEN ÜBER FIGUREN HINWEG, OHNE SIE ZU SCHLAGEN. Beschreibung Begriff Oberbegriff Unterscheidungs -merkmale Verweis auf anderen Begriff Synonym
CONTEXT HAT SEIN EIGENES GLOSSAR TIEFENZAHL PER ECHOLOT GEMESSENE TIEFE AN EINEM BESTIMMTEN ORT BEI NORMALNULL TIEFENMESSUNG TIEFENZAHL TIEFE AN EINEM BESTIMMTEN ORT UNTER BERÜCKSICHTIGUNG VON EBBE UND FLUT MANÖVER- PLANUNG
LEBENDIG: UBIQUITOUS LANGUAGE (ITERATION 2) Figuren Spieler Nichtmenschlicher Spieler Brett Foto: Fotograf Frank Hoppe/ Garry Kasparov/Wikipedia/PD-self Foto: Wikipedia/PD shape Foto: Wikipedia/CC BY-SA 3.0 Foto: Jim Gardner/Wikipedia/CC BY 2.0
LEBENDIG § Experimentiere mit alternativen Ausdrucksformen § Das Modell und die Sprache entwickeln sich weiter § Überarbeite dann den Code § Benenne Klassen, Methoden, Module § Entspreche dem neuen Modell § Eine Sprache will gesprochen werden: § Beseitige Unklarheiten durch Konversation Foto: Tkgd2007/Wikipedia/CC BY-SA 3.0
IN FACHSPRACHE DISKUTIEREN UND LÖSEN Entwickler unter sich: »Wie bauen wir das Housekeeping der Schiffssilhouetten-Tabelle in der Oracle-DB?« »Keine Ahnung, lass uns den Nautiker fragen.« Entwickler zum Nautiker: »Wie lange müssen Schiffssilhouetten aufbewahrt werden?« Nautiker: »Gar nicht mehr. Früher war das hilfreich, als wir sie noch aus Pappe basteln mussten. Jetzt mit der Software ist es so einfach, mal eben eine neue Silhouette anzulegen… das reicht völlig.« Entwickler am Rechner: »DROP TABLE Schiffsilhouetten;«
Softwareentwickler und Fachexperten sprechen verschiedene Sprachen § Wir brauchen eine gemeinsame Sprache à die Ubiquitous Language § Jeder Bounded Context hat seine eigene Ubiquitous Language § Jeder muss die Ubiquitous Language verwenden § Die Ubiquitous Language entwickelt sich im Projektverlauf weiter
KAPITÄN FRAGT NACH 7 SCHIFFS- SILHOUETTE AUF PEILDIENST PEILSCHIFF TIEFE PEILT 1 SENDET 2 AN B ER EC HNET 3 ERZEUGT 4 SENDET 5 PEILPLAN AN VERSCHIEBT & DREHT 8 SCHIFFS- SILHOUETTE UND FINDET 9 MELDET AN 6 ROUTE ROUTE PEILPLAN PEILPLAN TIEFEN- ZAHLEN ROUTE TIEFENLINIEN IM HAFEN Route finden Als ein Nautiker will ich die Schiffssilhouette verschieben und drehen, um eine Route zu finden Gibt es Beispiele hierfür?
BEISPIELE FINDEN MIT EXAMPLE MAPPING Es wird gewarnt, wenn eine Schiffsilhouette mit 5m Tiefgang auf einen Bereich mit 4m Wassertiefe bewegt wird. Bei einer Seekartentiefe von 5m und einem Tidenstieg von 0,4m (Flut) ist die Wassertiefe 5,4m Es ist alles ok, wenn eine Schiffsilhouette mit 5m Tiefgang auf einen Bereich mit 6m Wassertiefe bewegt wird. Bei einer Seekartentiefe von 5m und einem Tidenfall von 0,4m (Ebbe) ist die effektive Wassertiefe 4,6m Warnung bei zu geringer Wassertiefe Tidenhub beachten Als ein Nautiker will ich die Schiffssilhouette verschieben und drehen, um Route zu finden Wieviel Puffer braucht man unter dem Bug? Collaborative Modeling (Business + Dev/QA/UX) Beispiel / Szenario Regel / Akzeptanz- kriterium Funktionalität / User Story Frage
(SCENARIO) Funktionalität: Routenplanung Szenario: Warnung bei zu geringer Wassertiefe Gegeben sei eine Schiffsilhouette mit 5m Tiefgang Wenn die geringste Wassertiefe unter dem Bug 4m beträgt Dann soll eine Warnung ausgegeben werden. Szenario: Alles ok bei ausreichender Wassertiefe Gegeben sei eine Schiffsilhouette mit 5m Tiefgang Wenn die geringste Wassertiefe unter dem Bug 6m beträgt Dann soll keine Warnung ausgegeben werden. (Feature) (Scenario) (Given) (When) (Then) #language: de (Schlüsselwort) (Freitext)
FÜR DOKUMENTATION Funktionalität: Routenplanung Um eine sichere Route in den Hafen ermitteln zu können, soll der Nautiker beim verschieben der Schiffssilhouette Feedback über Untiefen erhalten. Der NAUTIKER ist die Person, die die Routenplanung vornehmen darf. Die ROUTE ist die Strecke, die das Schiff zum gefahrlosen einlaufen in den Hafen nehmen soll. Die SCHIFFSSILHOUTTE beschreibt die Ausmaße und Tiefe des Schiffs im Wasser. Szenariogrundriss: Warnung bei zu geringer Wassertiefe WASSERTIEFE ist die minimale Distanz zwischen Wasseroberfläche und Grund in einem Bereich. Sie berücksichtigt den Tidenhub (-> Tiefenhub.feature) zum Zeitpunkt der Simulation. Beispiele: Simulation für 09:10 Uhr (Flut) Routenplanung mit typischen Wasserständen bei Flut. Beispiele: Simulation für 15:48 Uhr (Ebbe) Routenplanung mit typischen Wasserständen bei Ebbe. User Story / Narrativ / Motivation Glossar / Begriffsdefinitionen Freitexte nutzen für z. B.
CUCUMBER UND JAVA (STEP DEFINITIONS) import io.cucumber.java.de.Gegebensei; import io.cucumber.java.de.Wenn; import io.cucumber.java.de.Dann; public class StepDefinitions { @Gegebensei("eine Schiffsilhouette mit 5m Tiefgang") public void eine_schiffsilhouette_mit_5m_tiefgang() { // Arrange } @Wenn("die geringste Wassertiefe unter dem Bug 4m beträgt") public void die_geringste_wassertiefe_unter_dem_bug_4m_beträgt() { // Act } @Dann("soll eine Warnung ausgegeben werden.") public void soll_eine_warnung_ausgegeben_werden() { // Assert } } Given: Vorbedingungen prüfen und Ausgangssituation herstellen When: Aktion durchführen oder Ereignis empfangen Then: Nachbedingungen und Ergebnisse prüfen Die Klasse wird für jedes Gherkin-Szenario intantiiert, Dann wird für jede Zeile im Szenario (given, when, then) die entsprechende Methode ausgeführt, Und wenn kein Fehler geworfen wird, ist der Test erfolgreich.
Introducing BDD, Dan North: https://dannorth.net/introducing-bdd/ § Specification By Example, Gojko Adzic § Writing Great Specifications, Kamil Nicieja § Example Mapping, Matt Wynne: https://cucumber.io/blog/2015/12/08/example-mapping-introduction § https://jbehave.org/ § https://cucumber.io/
§ Organisiert die Geschäftslogik in einzelne Prozeduren § Jede Prozedur deckt eine Anfrage vom Presentation Layer ab § Transaktionsklammern korrespondieren direkt mit Prozeduren § Kommunikation direkt oder nur über schlanken Adapter mit DB § Für einfache Probleme TiefenRechner berechneZoomstufe(peilplanNummer: long, zoom: byte): byte[][] Button UI- + Fachlogik persistente Fachdaten
§ Fachlogik in einer Klasse pro Datenbanktabelle implementiert § Algorithmen arbeiten direkt auf den ResultSets Peilplaene berechneZoomstufe(PeilplanNummer, zoom): byte[][] readPeilplan(PeilplanID) : ResultSet Fachlogik persistente Fachdaten
§ Typische OO-Modellierung § POJOs/POCOs/POPOs § Design unabhängig von Datenbank § OR-Mapping ist nötig § Verwendung von Konzepten wie Kapselung Peilplan berechneZoomstufe(zoom: Massstab): Zoomstufe Zoomstufe Persistenz Massstab Fachlogik + -daten Später wichtig: Wie passt das zu Schichtenarchitektur?
benannte Entities § Ohne fachliches Verhalten § Nur Getter und Setter § z.B. Java Beans § »Verkümmerte« Entities (= nur die Fachdaten) § Fachlogik nur in Services ANEMIC DOMAIN MODEL Foto: Vampire/Wikipedia/FAL PeilplanService berechneZoomstufe() Peilplan getTiefenzahlen() setTiefenzahlen()
MODELLIERT MAN EINE FACHDOMÄNE? Erweiterungs- aufwand Komplexität der Geschäftslogik Domain Model Table Module Transaction Skript Anemic DM Polluted DM
KRITIK MANÖVERPLANUNG User Interface Application Domain Infrastructure Domain-Schicht ist an Datenbank- Schicht gebunden à Technologie steigt hoch in die Fachlichkeit à Keine saubere Trennung von Fachlichkeit und Technologie!
ZU HEXAGONEN DOMAIN Port Port Port Port Port Port Adapter Adapter Adapter Adapter Adapter Adapter Web-UI Web- Controller (Servlet) http (Domain) Repo DB- Adapter DB Web-UI Web- Controller (Servlet) (Domain) Repo DB- Adapter DB http benutzt implementiert In welcher Schicht liegt der DB-Adapter? Aggre- gate
– Die 4 Grundsätze § The application is built around an independent object model § Inner layers define interfaces. Outer layers implement interfaces § Direction of coupling is toward the center § All application core code can be compiled and run separate from infrastructure à Leicht zu testender Anwendungskern à Passt gut zu TDD -- https://jeffreypalermo.com/2013/08/onion-architecture-part-4-after-four-years/ Jeffrey Palermo ! !
SZENARIO FE M« ILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- MESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN FE M« ILT TIEFENZAHL EINGE- ZEICHNET TIEFE AN PEILDIENST GEMELDET TIEFENZAHL »ROT« GEFÄRBT TIEFEN- LINIE GEZOGEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET UMLAUF- BAHN DES MONDES BERECHNET TIDEKURVE ERSTELLT SILHOUETT E DER LÄNGE 100M AUSGE- SCHNITTEN SILHOUETT E AUF ÖSTLICHE RICHTUNG GEDREHT SILHOUETT E 300M VER- SCHOBEN S PEILPLAN- ERSTELLUNG MANÖVER- PLANUNG TIEFEN- MESSUNG ZOOMSTUFEN- BERECHNUNG TIDE- VORHERSAGE
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG WER tut WAS WOMIT, um ausgehend vom Start-Event das End-Event zu erreichen? … …
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN
T LEGE MASSSTAB FÜR ZOOMSTUFE FEST ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN COMMAND Eine AKTION, DIE DURCHZUFÜHREN IST, um das nächste Event zu erreichen.
T LEGE MASSSTAB FÜR ZOOMSTUFE FEST ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LASSET UNS SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN Hängt das nicht eher von der Bildschirmauflösung ab, wie groß ein Bereich sein muss?
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN GERINGSTE TIEFENZAHL GEFUNDEN Hängt das nicht eher von der Bildschirmauflösung ab, wie groß ein Bereich sein muss?
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN Hängt das nicht eher von der Bildschirmauflösung ab, wie groß ein Bereich sein mus? GERINGSTE TIEFENZAHL GEFUNDEN
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE Hängt das nicht eher von der Bildschirmauflösung ab, wie groß ein Bereich sein mus? GERINGSTE TIEFENZAHL GEFUNDEN ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE Hängt das nicht eher von der Bildschirmauflösung ab, wie groß ein Bereich sein mus? GERINGSTE TIEFENZAHL GEFUNDEN ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN ZOOMSTUFE
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T LEGE MASSSTAB FÜR ZOOMSTUFE FEST ERZEUGE EINE NEUE ZOOMSTUFE ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN ZOOMSTUFE GELBER STICKIE HAUPTWORT Fachbegriff
SOFTWARE BAUEN ZUM ZOOMEN VON PEILPLÄNEN PEILPLAN GEZEICHNE T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE Hängt das nicht eher von der Bildschirmauflösung ab, wie groß ein Bereich sein mus? GERINGSTE TIEFENZAHL GEFUNDEN ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN ZOOMSTUFE TIEFENZAHL PEILPLAN MASSSTAB GRÖSSE BEREICH
T ZOOM- STUFE BERECHNET ZOOMSTUFEN- BERECHNUNG LEGE MASSSTAB FÜR ZOOMSTUFE FEST BESTIMME GRÖSSE DES BEREICHS EINER TIEFENZAHL TEILE DEN PEILPLAN AUF IN BEREICHE DIESER GRÖSSE FINDE DIE GERINGSTE TIEFENZAHL IN JEDEM DIESER BEREICHE ERSETZE DAMIT DIE TIEFENZAHLE N IN JEDEM DIESER BEREICHE ERZEUGE EINE NEUE ZOOMSTUFE Hängt das nicht eher von der Bildschirmauflösung ab, wie groß ein Bereich sein mus? GERINGSTE TIEFENZAHL GEFUNDEN ÜBERNIMM ALLE TIEFENZAHLE N AUS DEM PEILPLAN ZOOMSTUFE TIEFENZAHL PEILPLAN MASSSTAB GRÖSSE BEREICH TACTICAL EVENT STORMING
CRC-Karten Doku- ment Betreff Datum Register- abschnitt Ordner beschrift e wähle Dokument nach Betreff lege Register an kenn- zeichne füge ein Dokument nach Datum ein Stich- wort gib Stichwort vergleiche mit anderem Betreff füge Dokument ein entnimm Dokument • Nimm die Entities (gelb) und die Commands (blau) aus dem Event Storming. • Ordne die Commands den Entities, die sie verändern, zu.
CRC-Karten – Schritt 1 Doku- ment Betreff Datum Register- abschnitt Ordner beschrift e wähle Dokument nach Betreff lege Register an kenn- zeichne füge ein Dokument nach Datum ein Stich- wort gib Stichwort vergleiche mit anderem Betreff füge Dokument ein entnimm Dokument Zwei Fragen sind für die Zuordnung der Commands wichtig: • Welches Fachobjekt wird durch den Command verändert? • Welches Fachobjekt wird durch den Command sondiert? verändert den Ordner sondiert den Betreff
CRC-Karten – Schritt 2 Doku- ment Betreff Datum Register- abschnitt Ordner beschrift e wähle Dokument nach Betreff lege Register an kenn- zeichne füge ein Dokument nach Datum ein Stich- wort gib Stichwort vergleiche mit anderem Betreff Doku- ment Betreff Datum Register- abschnitt Stich- wort füge Dokument ein entnimm Dokument Betreff • Füge den Fachbegriffen ihre Collaborators (pink) hinzu. Doku- ment à Collaborators sind andere, von einem Command benötigte Fachbegriffe! Nicht mit Akteuren verwechseln!
– FERTIG! Doku- ment Betreff Datum Register- abschnitt Ordner beschrift e wähle Dokument nach Betreff lege Register an kenn- zeichne füge ein Dokument nach Datum ein Stich- wort gib Stichwort vergleiche mit anderem Betreff füge Dokument ein entnimm Dokument • Ersetze Collaborators (pink) durch Pfeile. à Ergebnis: Klassendiagramm!
werden in ihrem Verhalten fachlich modelliert ... ... und softwaretechnisch in fachlichen Klassen beschrieben. Laenge Position public class Silhouette { void verschiebeUm(Laenge len) { assert len != null; // ... position.add(len)); } } Fachliche Gegenstände… VERSCHIEBT LÄNGE SILHOUETTE SILHOUETTE VERSCHOBEN VERSCHIEBE UM SILHOUETTE NAUTIKER 8
FACHLICHEN KLASSEN Das Konzept der Modellierung von fachlichen Klassen: • Wähle anwendungsfachliche Begriffe (à als Substantiv) • Beschreibe Umgangsformen (à als Verb) und die dabei benötigten weiteren Gegenstände. Keine Daten modellieren. Schiff-Silhouette Verschiebe Drehe Position? Länge ü.a.? Breite? ...
FACHLICHEN UMGANGSFORMEN AN SCHNITTSTELLEN Umgangsformen: die Art und Weise, wie mit Gegenständen im Rahmen der verschiedenen Aufgaben gearbeitet wird. Wir untersuchen: § Welche Informationen werden an den Gegenständen "abgelesen"? § Welche Veränderungen werden an den Gegenständen vorgenommen und welche Aktionen werden ausgelöst, ohne dass sie zerstört oder in andersartige Gegenstände transformiert werden? àCQS-Prinzip von Bertrand Meyer Schiff-Silhouette • Verschiebe • Drehe • Position? • Länge ü.a.? • Breite? ...
Methode soll entweder § Zustand ändern è Command § Zustand auslesen è Query § Aber nicht beides! § D.h. das Auslesen eines Zustands sollte keine Seiteneffekte haben! § Sonst drohen Risiken und Nebenwirkungen. COMMAND-QUERY-SEPARATION PRINCIPLE
PRINCIPLE (DIP) a. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces). b. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. Robert C. Martin ”Uncle Bob“ – https://web.archive.org/web/20110714224327/http://www.objectmentor.com/resources/articles/dip.pdf
Wir bauen einen fachlichen Anwendungskern pro Bounded Context § Dieser enthält die Fachlogik und ist frei von UI und Infrastruktur-Code § Infrastruktur wird über Adapter angebunden (Dependency Inversion / Dependency Injection)
Objekte einer Fachdomäne, die der Anwender bearbeitet § An ihnen schlagen sich die Arbeitsergebnisse nieder! § Können aus anderen Entities zusammengesetzt sein § Besitzen unveränderliche Identität § Sichern ihre eigene Konsistenz und Integrität § Haben klar definierten Lebenszyklus § Besitzen einen (meist veränderlichen) Zustand § Beschreiben ihren Zustand mit Value Objects § Synonyme: Business Object / Domain Object / Material § NICHT ZU VERWECHSELN mit dem Begriff »Entity« aus dem Entity-Relationship-Modell! Foto: Bundesrepublik Deutschland/Wikipedia/PD Germany Foto: Thomas G./Wikipedia/CC BY-SA 3.0
§ Value Objects sind Symbole für Werte eines bestimmten Typs in der Fachdomäne § Identitätslos § Symbolisieren bei Gleichheit denselben Wert § Sie werden vom Anwender nicht bearbeitet und sind unveränderlich § Können ggf. (aus anderen Value Objects) berechnet werden § Können aus anderen Value Objects bestehen, aber nie aus Entities! § Synonyme: Fachwert, Wert, Whole Value ValueObject 2,5 ValueObject ValueObject ValueObject ValueObject zwei- einhalb
– WEITERES § Whole Value (Tiefe = „100 cm“ statt TiefeInCentimeter = „100“) § Methoden dürfen Zustand nicht verändern, aber »neue« Value Objects zurückgeben § In Java < 14 viel Boilerplate-Code nötig § è Project Lombok: @Value § è ab Java 14: record types § Operators / Operator Overloading (je nach Sprachunterstützung) § Der gleiche Begriff kann im einem Bounded Context Entity sein und im anderen Value Object à https://c2.com/ppr/checks.html
Aggregates sind Entities, die für sich genommen relevant sind (und nicht nur als Teil einer anderen Entity) § Schützen Konsistenz und Integrität ihrer inneren Entities § Besitzen grundsätzlich eine gekennzeichnete Entität als Einstiegspunkt (Wurzel / Root) § Werden üblicherweise persistiert § Als Ganzes! § Nicht notwendigerweise relational! § Synonyme: Composite (UML) Root Entity Entity Entity Entity Aggregate Entity (Single-Entity) Aggregate
IN ENTITIES / AGGREGATES § Value Objects sind unveränderlich und können von beliebiger Stelle referenziert werden. àTechnisches Implementierungsdetail, z.B. in Java àKönnen natürlich auch direkt in einer Entity als Wert eingebettet sein, z.B. via Structs in C# àUnveränderlichkeit heißt es ist egal, ob man eine geteilte Instanz oder beliebig viele Kopien des Wertes hat, und ob sie separat auf dem Heap oder eingebettet im Objekt liegen àWahl kann Performance-Auswirkungen haben Root Entity VO VO VO Aggregate Irgendein anderes Objekt
AGGREGATES § Aggregates referenzieren sich gegenseitig nur über (Wurzel-Entity) IDs, nicht über Objektreferenzen § Sofortige Konsistenz nur innerhalb eines Aggregates; über mehrere gilt Eventual Consistency Bestellung Position 1 4711 Position 2 Artikel Artikel Position 3 4711 4812 ID: 4711 ID: 4812
Sind die Zugriffspunkte auf die Aggregates! § Kapseln die technischen Details der technischen Infrastrukturschicht § Bilden Daten auf fachliche Entities und Value Objects ab § Persistieren Entities z. B. in Datenbanken Repository Aggregate Aggregate Aggregate Aggregate Aggregate
SERVICES § (Domain) Services stellen Abläufe oder Prozesse der Fachdomäne dar § Und zwar solche, die nicht von Aggregaten ausgeführt werden können / sollen § Sie sind zustandslos! § Parameter und Ergebnisse ihrer Operationen sind Entities und Value Objects Aggregate Entity Value Object Aggregate Value Object Entity Aggregate Value Object Entity Value Object
DOMAIN EVENTS § Sind aus fachlicher Sicht relevant § Ereignisse sind bereits geschehen § NICHT die Dinge, die erst noch geschehen sollen! § Einige Bounded Contexts reagieren auf diese fachlichen Ereignisse, andere nicht § Werden zur Kommunikation zwischen Bounded Contexts verwendet § fördern deren Entkoppelung § erleichtern asynchrone Prozesse § Werden oft mithilfe von Messaging ausgetauscht
§ Klassische Speicherung von Aggregaten: § Der Zustand als Ganzes wird gespeichert § Commands ändern Felder § Event Store § Die (zustandsändernden) Ereignisse werden gespeichert § Commands fügen Events hinzu § Append-only § Es gibt kein Löschen von Events § Aber stornierende Events § Aggregate-Zustand wird durch Replay der Events wiederhergestellt § History-Funktion § Snapshots für Performance bzw. nach Abschluss gewisser Geschäftszeiträume (Geschäfts-Tag / Monat / Jahr)
IM HAFEN Beispielszenario: Zustandsspeicherung: Event Sourcing: § Silhouette an Position A Position = A Position = A § Verschiebe um 50m Position = B Verschoben um 50m § Drehe um +30° Position = C Gedreht um +30° § Verschiebe um 100m Position = D Verschoben um 100m § Drehe -30° Position = E Gedreht um -30° § Silhouette an Position Z Position = Z Position = (A+50m, +30°,+100,-30°) = Z
Factories erzeugen Aggregates (und ggf. auch Value Objects) § Aggregates und Value Objects müssen nicht unbedingt über Factories erzeugt werden. § new Peilplan() ist ok! § Kapseln komplexe Erzeugungslogik § Erhalten Invarianten à erstellt fertiges Aggregat § Siehe auch Factory und Builder Pattern der GOF Factory Aggregate Aggregate ValueObject Aggregate ValueObject
Anwendungsfälle § Dienen dem technischen Zugriff auf den Domain Layer. § Nutzen Fachlogik aus dem Domain-Layer, implementieren selbst aber keine Fachlogik! § Liegen im Application-Layer (OBERHALB des Domain-Layers)! § Bieten ein API / bilden eine Fassade. § Eher Technik-getrieben § Transaktionen § Security § Backend for Frontend APPLICATION SERVICE Foto: Fotograf Andreas Praefcke/Wikipedia/PD-self
DES DOMAIN-KERNELS User Interface Infrastructure Application Domain Service Factory Aggregate Value Object Repository Root Entity Entity Domain Event Application Service (Adapter) (Adapter) (Adapter) (Adapter)
RepoInMemory Repo RepoTest • Repo: Interface des Repositorys à „Syntax“ • RepoTest: Akzeptanz-Tests/Unit-Test für das Repository à »Semantik« • RepoInMemory: Referenz-Implementierung des Repositorys • Ohne Persistenz. • Nutzbar als (umfassend getesteter) »Mock« in fachlichen Tests. • Schnell im Mob zu realisierende Implementierung. Aggregate NOCHMAL GENAUER
fine grained model repository interface controller use case service entity value object view data model repository implementation widget library REST frame- work transaction handling domain library programming language ORM file system access domain event Henning Schwentner !
STRUKTURIERUNG EINES FACHLICHEN KERNS MANÖVER-PLANUNG SILHOUETTE MODUL TIDE MODUL PEILPLAN MODUL Peilplan Markierung ZoomService Peiplan Repository Tiefe Position Silhouette Silhouette Repository TideService Tageszeit
N EN - L ER N EN A U F - T E IL E N SPRACHE MODELL CODE Event Storming Subdomains Domain Storytelling Core, Supporting, Generic Subdom ains Bounded Contexts Brownfield Development Context Maps Ubiquitous Language BDD, Example Mapping Hexagonal Architecture Entities Microservices Event Sourcing Collaborative Modelling Value Objects Services Events Building Blocks Aggregates Repositories Scenario Casting / Orientierungsszenario
WPS § Foundation Level § Trainingslager Softwarearchitektur (iSAQB® Foundation Level) § Advanced Level § DDD konkret (iSAQB® Modul DDD) § Agile Architektur konkret (iSAQB® Modul AGILA) § Architekturbewertung konkret (iSAQB® Modul ARCEVAL) § Softwarearchitekturen verbessern (iSAQB® Modul IMPROVE) § Microservices und DevOps konkret (iSAQB® Modul FLEX) § Infrastruktur, Container, Cloud-Native (iSAQB® Modul CLOUDINFRA) § Web Security (iSAQB® Modul WEBSEC)
wps
geekplus_tech
kntkymt
simas
takter00
kuranuki
manfredsteyer
yoshikouki
nrslib
vinceamstoutz
naokihaba
denniskardys
akihiro_kokubo
jakevdp
chriscoyier
axbom
chrisshort
gurzu
cromwellryan
frankvandijk
mfonobong
mayunak
speakerdeck
![Prinzipien hinter dem Agilen Manifest Wir folgen diesen Prinzipien: […]](https://files.speakerdeck.com/presentations/068cdc25ed8e4487beae4777dc785a93/slide_175.jpg){kind=link}
