Das Wesen von Software • Bausteine Domain-driven Design • Schichtenarchitektur mal anders • Messaging und WebServices • Weiterführende Themen • Diskussion
Seite 4 • Ein MONSTRÖSES Projekt • Sie wollten zu viel auf einmal • Sie haben sich mit höheren Mächten angelegt • Dafür wurden sie mit Sprachverwirrung bestraft • Die Projektbeteiligten haben sich nicht mehr verstanden • Zum Schluss gingen alle getrennte Wege • Übrig blieb eine Ruine
5 • Wir haben grosse Projekte • Wir haben ehrgeizige Ziele • Wir haben wenig Zeit • Manchmal auch Sprachverwirrung • Verstehen wir unsere Kunden wirklich? • Niemand will eine Ruine Und das alles gibt es gratis ohne biblischen Fluch ;-)
6 • Software ist immateriell • Sie besteht aus den Sprachen und Notationen, in denen sie formuliert ist • Software ist auch ein Modell • Ein Modell ist die Abbildung eines Realitätsausschnitts • Modell = Struktur + Verhalten • Das Modell definiert die Umsetzung der Anforderungen unserer Stakeholder
Sache Seite 7 Der Informatiker(Wir) Der Kunde(Vertrieb) Welches Framework? Der Webshop muss gut Welche Programmiersprache? aussehen Es geht um einen Webshop… Der Kunde(Finanzbuchhaltung) Ich brauche eine Statistik über Quartalszahlen Modell
8 • Wir brauchen einen Überblick • Wir brauchen eine Diskussionsgrundlage • Wir müssen Zusammenhänge verstehen • Wir brauchen einen (Bau)Plan unserer Software
Abgrenzung • Nichtberücksichtigung irrelevanter Objekte • Dekomposition • Zerlegung und Auflösung in einzelne Segmente(Teilmodelle) • Reduktion • Weglassen von Objektdetails • Aggregation • Vereinigung von Segmenten zu einem Ganzen • Abstraktion • Begriffs- bzw. Klassenbildung
10 • Jein! • Object Oriented Programming vs. Object Based and Data Centric Programming(DCP) • DCP bricht schnell zusammen, weil • Prozedural programmiert wird und • die Möglichkeiten von OOP nicht ausgenutzt werden • «OOP isn’t about creating re-usable classes, it is about creating usable classes»
Ist eine Methode, um Systeme zu modellieren verwandt mit Systems Engineering Ist kein PM-Vorgehensmodell wie z.B. HERMES oder V-Modell Hilft uns, Komplexität im Griff zu behalten
• DDD ist eine Herangehensweise an die Modellierung komplexer (objektorientierter) Software • Der Begriff wurde von Eric Evans geprägt. Er nennt sich selbst einen «Domain Linguist» • Es ist mehr als eine Technik oder Methode, es ist eine Denkweise zur Steigerung der Produktivität im Umfeld komplexer fachlicher Zusammenhänge • Der Schwerpunkt des Modells liegt auf Fachlichkeit und Fachlogik • Das Modell spricht eine eigene, allgegenwärtige Sprache, welche von allen Projektbeteiligten verstanden wird
evolvierende Struktur • Unser Modell ist nicht von Anfang an perfekt, es lebt und wird laufend verfeinert und erweitert • definiert ein System • und das Zusammenspiel von Teilsystemen mittels Schnittstellen und Ereignissen • bildet Fachwissen ab • durch Einsatz der allgegenwärtigen Sprache
Vorgehensweisen • Iteratives Vorgehen und schrittweises Verfeinern des Modells ist klar gewünscht • Das Modell ist nicht nur ein Artefakt • es ist ein Kommunikationsmittel zwischen Stakeholdern, Lieferanten und Projektmitarbeitern • Software = Modell, Modell = Software • DDD geht mit jeder Programmiersprache, wird aber primär im OO Umfeld eingesetzt
• Domain • Ist der sog. Problembereich(Problemspace). Hier wird das zu lösende Problem oder die zu lösende Aufgabe beschrieben • Bounded Context • Ist der sog. Lösungsbereich(Solutionspace). Ein Bounded Context beschreibt, wie eine Funktionalität in der Software umgesetzt wird. Ein Bounded Context ist in der Regel ein Subsystem oder eigenständiges Lieferobjekt. • Domain und Bounded Context sollten sich überlappen
• Entity • Ein Ding aus der echten Welt, welches eine eindeutige ID hat. Ein Entity entspricht nicht einer Datenbanktabelle! • Value Object • Ist kein Ding, sondern ein Wert wie z.B. ein Geldbetrag oder auch eine Postanschrift. Ein Value Object hat keine eindeutige ID • Aggregate • Ein Aggregate sorgt dafür, dass eine Geschäftsregel eingehalten wird, z.B. kein Versand ohne Lagerbuchung
Entities sind keine JavaBeans • Nicht jedes Attribut braucht eine Get- und Setmethode. Dies würde die Kapselung unterwandern • Value Object sind immutable • Sie können ihren Zustand nicht verändern und müssen immer komplett ersetzt werden. Sehr gut geeignet für Multi- Threaded Systeme. Stichwort «Functional Objects». • Aggregates kapseln Zugriff • Von aussen kann nur auf das Aggregate Root zugegriffen werden. Dadurch wird der Zugriff auf komplexe Objektgraphen gekapselt und Impl.-Details versteckt.
• Aggregates sind Entities mit zusätzlichen Aufgaben • Aggregate = Objektgraph • Aggregate verweisen auf andere Aggregate via ID, und nicht via Objektreferenz • Faustformel: Ein Aggregate kapselt Zugriff auf max. 2-3 Entities • Sinnvoll angewendet führen sie zu weniger LazyInitializationExceptions • Keine Tuning der Hibernate Mappings mehr nötig, in der Regel wird Eager-Loading verwendet
Entities und Aggregates werden von Factories oder Buildern erzeugt. Ein direkter Aufruf von «new» ist verboten • Entities und Aggregates werden über Repositories persistiert • Entities und Aggregates können über Repositories rekonstituiert werden • Ein Repository ist kein DAO, da es Teil des Fachmodells und kein technisches Artefakt ist
Umwelt muss mit den Bounded Contexten interagieren • Der Bounded Context stellt dafür Schnittstellen zur Verfügung • Diese Schnittstellen heissen Domain Services • Ein Domain Service verhält sich wie eine Fassade, er kapselt Komplexität
• Ein Name ist ein Name und kein String • Immutable Objects bevorzugen • Soviel Logik wie möglich in Value Objects packen • Command-query separation einhalten(CQS Principle) • Lesender Code liefert ein Ergebnis und ist nicht destruktiv • Schreibender Code verändert einen Zustand, ist aber immer vom Typ void. Aussnahme : Domain Services • Eigenständige Methoden für lesenden und schreibenden Code • Single responsibility principle einhalten(SRP)
für strikte Schichtentrennung • Transitive Abhängigkeiten sind auch Abhängigkeiten • Geschäftslogik ist indirekt abhängig von der Infrastruktur • Stammt noch aus J2EE Zeiten(1999) cmp Klassische Schichten User Interface Layer + LieferungPresenter + LieferungView + LieferungViewModel Business Layer + LieferungService Data Access Layer + LieferungDAO + hibernate Infrastructure Layer + DataSource
Aufruf) • Nutzung von SOAP oder REST • REST bevorzugen, da durch Proxy-Server cachebar(Stichwort etag und expiry-time im HTTP Header)! • Asynchrone Abfrage(nicht blockierend) • Nutzung von JMS oder AMQP • Immer Double-Dispatch von Nachrichten, da Messaging System nicht verfügbar sein kann
SOAP? • Abfrage des Lagerbestandes ist häufig • Muss das immer neu berechnet werden? • Können wir das nicht cachen? • REST GET Request bevorzugen, z.B. http://mydomain/artikel/<Artikelnummer>/bestand.json • Kann von Proxy-Servern gecached werden, Stichwort Etag und Expiry-Time
DDD kennt das Konzept von sog. Domain Events • Ein Domain Event ist ein fachliches Ereignis, z.B. Kunde hat Bestellung aufgegeben • Domain Events werden von einem Bounded Context produziert und können von anderen Bounded Contexten konsumiert werden • Aber Achtung: Events müssen gecached werden, da z.B. auch die Messaging Middleware nicht verfügbar sein kann. Daher immer Double-Dispatch! • Events immer mit Zeitstempel und eindeutiger ID. So kann Reihenfolge und Verarbeitung protokolliert werden
von einem Aggregate erzeugt und in einem EventRepository persistiert • Im Infrastructure Layer gibt es einen Timer, welcher das EventRepository ausliest und bei Verfügbarkeit der Messaging Middleware(JMS / AMQP) weiterleitet • In konsumierenden Bounded Context gibt es im Infrastructure Layer einen MessageListener, welcher auf Nachrichten hört • Diese Nachrichten werden via ApplicationService an die Geschäftslogik übergeben. Deshalb muss Infrastructure Layer auch ganz oben und nicht ganz unten sitzen!
Service(OHS) • Ist eine Sammlung von Services, welche von einem Bounded Context zur Verfügung gestellt werden • Anti-corruption Layer(ACL) • Adapter von einem Bounded Context für den Zugriff auf den OHS eines anderen Bounded Context • Generic Subdomain • Beinhaltet gemeinsame Typen, wie z.B. KundenId oder ArtikelID, aber keine Geschäftslogik
Spezifikation wurde ursprünglich für GUI Widgets erstellt • 0-Arg Konstruktor • Public Getter und Setter für Properties • Optionale BeanInfo Klassen • Niemand sagt, dass alles eine JavaBean sein muss! • Hibernate kann seit Version 2 auch Field-Access, keine Setter und Getter mehr notwendig, JPA kann das auch • Es reicht auch ein Package-Visibility 0-Arg Konstruktor
wie z.B. Interfaces und Domänenobjekte können aus dem Modell generiert werden • Für Enterprise Architect gibt es die MDG Erweiterungen • Dadurch bleibt Modell und Code synchron • Für dynamisches Verhalten ist UML eher ungeeignet • Die DDD Prinzipien können auf alle OO-Sprachen übertragen werden, DDD unterstützt auch funktionale Programmierung • Arc42 Framework für Dokumentationen
mirkosertic
yagieng
amaltson
ditn
martinlippert
julep
jimhester
atp
mu_zaru
hideokamoto
palkan
dalinaum
rasmusluckow
jonyablonski
colly
trishagee
revolveconf
jrom
chriscoyier
reverentgeek
garrettdimon
davidbonilla
pauljervisheath
tmm1
