Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Mit Domain-Driven Design (DDD)
nützliche und flexible Software
bauen
Konzepte und Methodik im Überblick
Nicole Rauch und Ar...
Unsere aktuelle Architektur
User
Interface
Business
Layer
Datenbank
Layer
Unsere aktuelle Architektur
User
Interface
Business
Layer
Datenbank
Layer
KundenEditUI
KundenEditModel
KundenBS
KundenDTO
...
Domain-Driven Design
Domänen-Experten und Entwickler gemeinsam
Fokus der Entwicklung auf die Fachlichkeit
Bausteine und We...
Literatur
Baustein: Entität
hat eine Identität (beschreibt das „wer“)
hat einen Lebenszyklus
Modellierung fokussiert darauf
eindeuti...
Baustein: Value Object
Wert
hat keine Identität (beschreibt „was“, nicht „wer“)
fachlicher Wrapper um technische Datentype...
Einige Wochen später...
Neues über Value Objects
aus Entitäten auslagern
können auch komplexer aufgebaut sein
entwickeln sich zu „Code-Magneten“
Die allgegenwärtige und gemeinsame Sprache
Ubiquitous Language
Fachbegriffe überall verwenden, auch im Code!
Glossar zur B...
Baustein: Aggregate
besteht aus Value Objects und Entities
Aggregate Root als Einstiegspunkt
gemeinsame Invarianten und Ko...
Domain Services
Hinweis auf fehlenden Service: Code in static Methoden
zustandslos
oft als Einstieg in die Domäne
Domain Services Revisited
zu viel Code in Services
prozedurale Programmmierung
blutleeres Modell
zu viel Code in Entitäten...
Repositories
fachliche Schnittstelle zu Daten
gaukeln In-Memory-Collection vor
keine Infrastruktur-Abhängigkeiten in Domai...
Repositories
KundeDatabaseRepository
KundeService
KundeRepository Kunde
Business Layer
DB Layer
Repositories
DB-Adapter
HTTP
KundeService
KundeRepository
Kunde
KundeDatabaseRepository
REST
Filesystem
Gründe für Anpassungen am Modell
Grund Nummer 1: Lernen
bessere Begriffe
Beziehungen werden klarer
neue Konzepte/Abstrakti...
Und sie programmierten glücklich
bis an ihr Lebensende. . .
Achtung!
Technisches nicht hinten runterfallen lassen
Vorsicht vor blutleeren Modellen - Code in die Objekte!
Services sol...
Positive Aspekte
Fokus auf Fachlichkeit und gemeinsamer Sprache
gutes Zusammenspiel mit Specification by Example bzw.
Accep...
Vielen Dank!
Folien auf GitHub:
https://github.com/NicoleRauch/DomainDrivenDesign
Schulung bei Digicomp:
Domain-Driven Des...
Mit Domain-driven Design (DDD) nützliche und flexible Software bauen
Mit Domain-driven Design (DDD) nützliche und flexible Software bauen
Mit Domain-driven Design (DDD) nützliche und flexible Software bauen
Upcoming SlideShare
Loading in …5
×

Mit Domain-driven Design (DDD) nützliche und flexible Software bauen

555 views

Published on

Domain-driven Design liefert die passenden Strukturen von Domänen, bildet diese optimal in Design und Code ab und hält sie dort am «Leben». So werden auf Fachlichkeit ausgerichtete, langfristig erweiterbare und wartbare Applikationen Wirklichkeit.

In ihrem Referat rissen Nicole Rauch und Arif Chughtai die Vorgehensweise grob an, die zu den Strukturen einer Domäne führen und zur Strukturierung einer gesamten Applikation eingesetzt werden (Crunching Knowledge, Ubiquitous Language, Bounded Contexts etc.). Anschliessend wurden die Software-Bausteine näher beleuchtet, aus denen Applikationen zusammengesetzt werden (Entities, Value Objects, Aggregates, Factories, Repositories, Services etc.).

Zum Abschluss wurde das Architektur-Design betrachtet, in dem die genannten Software-Bausteine eingebunden sind Hexagonal Architecture (Ports and Adapters, Onion)).

Gerne stellen wir Ihnen die Slides des Referats zur Verfügung.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mit Domain-driven Design (DDD) nützliche und flexible Software bauen

  1. 1. Mit Domain-Driven Design (DDD) nützliche und flexible Software bauen Konzepte und Methodik im Überblick Nicole Rauch und Arif Chughtai 2. März 2016
  2. 2. Unsere aktuelle Architektur User Interface Business Layer Datenbank Layer
  3. 3. Unsere aktuelle Architektur User Interface Business Layer Datenbank Layer KundenEditUI KundenEditModel KundenBS KundenDTO KundenPS KundenDAO KundenVO
  4. 4. Domain-Driven Design Domänen-Experten und Entwickler gemeinsam Fokus der Entwicklung auf die Fachlichkeit Bausteine und Werkzeuge für gute Anwendungen
  5. 5. Literatur
  6. 6. Baustein: Entität hat eine Identität (beschreibt das „wer“) hat einen Lebenszyklus Modellierung fokussiert darauf eindeutigen Identifikator festlegen
  7. 7. Baustein: Value Object Wert hat keine Identität (beschreibt „was“, nicht „wer“) fachlicher Wrapper um technische Datentypen bildet eine konzeptionelle Einheit kann oft als Immutable implementiert werden dann ist Sharing möglich
  8. 8. Einige Wochen später...
  9. 9. Neues über Value Objects aus Entitäten auslagern können auch komplexer aufgebaut sein entwickeln sich zu „Code-Magneten“
  10. 10. Die allgegenwärtige und gemeinsame Sprache Ubiquitous Language Fachbegriffe überall verwenden, auch im Code! Glossar zur Begriffsklärung muss reichhaltig genug sein für sämtliche Kommunikation beschreibt nicht nur die Einheiten im System, sondern auch Aufgaben und Funktionalitäten muss widerspruchsfrei und eindeutig sein Bounded Context, um grosse Domänen zu strukturieren
  11. 11. Baustein: Aggregate besteht aus Value Objects und Entities Aggregate Root als Einstiegspunkt gemeinsame Invarianten und Konsistenzbedingungen Zugriff auf Elemente über die Root
  12. 12. Domain Services Hinweis auf fehlenden Service: Code in static Methoden zustandslos oft als Einstieg in die Domäne
  13. 13. Domain Services Revisited zu viel Code in Services prozedurale Programmmierung blutleeres Modell zu viel Code in Entitäten Überfrachtung der Entitäten mit Verhalten Verlust konzeptioneller Klarheit Abhängigkeiten an der falschen Stelle
  14. 14. Repositories fachliche Schnittstelle zu Daten gaukeln In-Memory-Collection vor keine Infrastruktur-Abhängigkeiten in Domain Code
  15. 15. Repositories KundeDatabaseRepository KundeService KundeRepository Kunde Business Layer DB Layer
  16. 16. Repositories DB-Adapter HTTP KundeService KundeRepository Kunde KundeDatabaseRepository REST Filesystem
  17. 17. Gründe für Anpassungen am Modell Grund Nummer 1: Lernen bessere Begriffe Beziehungen werden klarer neue Konzepte/Abstraktionen tauchen auf
  18. 18. Und sie programmierten glücklich bis an ihr Lebensende. . .
  19. 19. Achtung! Technisches nicht hinten runterfallen lassen Vorsicht vor blutleeren Modellen - Code in die Objekte! Services sollten die Ausnahme sein, nicht die Regel klassische Schichtenarchitektur kann suboptimal sein
  20. 20. Positive Aspekte Fokus auf Fachlichkeit und gemeinsamer Sprache gutes Zusammenspiel mit Specification by Example bzw. Acceptance Test-Driven Development (ATDD) Value Objects entlasten Entitäten und ziehen Code an keine Angst vor Veränderungen - Code geschmeidig halten
  21. 21. Vielen Dank! Folien auf GitHub: https://github.com/NicoleRauch/DomainDrivenDesign Schulung bei Digicomp: Domain-Driven Design - Lernen Sie Software mit optimalem Geschäftsnutzen zu entwickeln Nicole Rauch E-Mail info@nicole-rauch.de Twitter @NicoleRauch Arif Chughtai E-Mail mail@arifchughtai.org

×