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
Mirko Sertic
mirkosertic
rosylilly
ykanoh
pluu
po3rin
uzimaru0000
tkmru
yuzujoe
takahiro901
bells17
yusuke57
hannaprinz
yuki384
malarkey
trishagee
afnizarnur
hannesfritz
ammeep
addyosmani
maggiecrowley
chriscoyier
morganepeng
swwweet
frogandcode
jacobian
