J and I and Me
2006-10-04
  JAOO 2006: Eric Evans - Domain Driven Design
Leider konnte ich nur den zweiten Teil von Eric Evans Session besuchen. Er hat mit Domain-Driven Design eines der wichtigeren Bücher der letzten Jahr geschrieben und über dieses Thema hat er auch gesprochen.

Er fing damit an, darzustellen, dass es nur ein begrenzte Team-Größe gibt, die man noch sinnvoll koordinieren kann. Als Beispiel, um dies zu illustrieren, wählte er Ruderboote: Es gibt nur maximal einen 8er, weil darüber hinaus die Koordinierung nicht mehr möglich ist.

Als nächstes stellte er die These auf, dass in einem großen System nicht alle Teile gleichgut designt sein werden. Daher rät er dazu, den Umfang zu reduzieren. Außerdem ist er der Meinung, dass präzise Designs auch dazu neigen, fragil zu sein. Das ist insbesondere schlecht, wenn um das gute Design herum Chaos herrscht.

Also rät er dazu, Grenzen in das System einzuziehen und an den Grenzen auch jeweils ein Mapping einzuführen, so dass unterschiedliche Modelle für unterschiedliche Anwendungsfälle möglich sind. Man hat also dann Grenzen im System und innerhalb dieser Grenzen ist ein Modell dann einsetzbar. Interessanterweise stellt dies natürlich völlig in Abrede, dass man ein generelles, universelles Objekt-Modell erstellen kann, wie es eigentlich zum Beispiel für eine SOA sinnvoll erscheint.

Ein weitere Maßnahme, die er dann vorstellte, war ein Anti-Corruption Layer. Dies wird dazu benutzt, um zwei unterschiedliche Teile des Systems voneinander zu entkoppeln. Idealerweise sollte es die beiden Teile hermetisch voneinander abgrenzen, in der Realität haben sie allerdings oft ein Leck, so dass man dann Probleme bekommt - und bereits bei recht kleinen Lecks recht große. Die Übersetzung der Modelle der verschiedenen System-Teile wird dabei in die Grenzen verschoben, um die Teile möglichst gut voneinander zu entkoppeln und innerhalb des Systems Konsistenz mit einem einzigen Modell zu erreichen. Als Metapher wählte er die biologischen Zellen, die ja auch durch Zellwände voneinander entkoppelt sind.

Für die Visualisierung schlägt er Context Maps vor, die darstellen, an welchen Stellen des Systems welche Modelle verwendet werden. Für Verbesserungen schlägt er vor, zunächst das darzustellen, was vorhanden ist, dann die echten Probleme zu beseitigen und nachdem man tatsächlich diese Änderungen vorgenommen hat, sollte man eine neue Context Map erstellen.

Anschließend kam er zu dem Thema des "Destillierens" der Core Domain. Seiner Meinung nach zerfällt ein System in drei unterschiedliche Bereiche:


Die Frage, die dabei beantwortet werden muss, ist: "Was ist es, was die Entwicklung des Systems rechtfertigt? Warum kann man es nicht kaufen oder outsourcen? Und warum kann man es nicht einfach mit Visual Basic bauen?"

Seiner Meinung nach ist es oft nicht so einfach, die Core Domain zu identifizieren, da man dazu verstehen muss, was der Anwendungsfall genau ist und vor allem, was der Wettbewerbsvorteil ist. Als Beispiel wählte er den Versand von Containern: Obwohl eigentlich das Ziel des Projekts ist, den Versand zu optimieren, indem man Container während der Reise noch auf einen anderen Weg schicken kann. Dennoch hat die Firma als Wettbewerbsvorteil, dass der Versand mit ihr besonders reibungslos ist. Daher sollte man darauf fokussieren. Was mich dabei irritiert ist, das auf diesem Wege eine Management-Entscheidung über der Fokus des Projekts getroffen wird und das möglicherweise auf einer Ebene, die solche Entscheidungen nicht treffen sollte.
  17:53
Bookmark and Share
Comments:
Wieso ersheint es für eine SOA sinnvoll zu sein, ein universelles Objekt-Modell zu erstellen? Wäre es denn nicht viel eher so, dass die Grenzen, die man in das System einzieht in einer SOA die Services der Teilnehmer sind, und somit ein universelles Objekt-Modell von vorne herein kein gangbarer Lösungsweg ist?

Immerhin besteht die integrative Aufgabe im SOA-Bereich ja eben darin bedingt inkompatible Objekt-Modelle auf Service-Ebene miteinander einen Vertrag eingehen zu lassen. Deshalb ja auch die Transformations- und Aggregationsmechanismen auf ESB-Ebene.

Bei einer SOA von der grünen Wiese kann ein gewisses Maß an rücksichtnahme und Kompatibilität-by-Design für die Allgemeingültigkeit (und somit auch für die Wiederverwendbarkeit) eines Services eher schädlich sein.

Daher frage ich mich, ob ein universelles Objekt-Modell für eine SOA wirklich relevant ist - oder nicht sogar unerwünscht.

Viele Grüße,
M.
 
Wenn man eine SOA aufbaut und Services hat, die zum Beispiel verschiedene Funktionalitäten zur Verwaltung von Kunden zur Verfügung stellen, dann erscheint es sinnvoll, dass alle Services von einem gemeinsamen Kunden-Modell ausgehen. Wichtig ist dabei auch das "erscheint": Scheinbar hat man so weniger Aufwand. In Wirklichkeit ist es halt ein Problem - wie im Kommentar richtig dargestellt. Allerdings würde ich das universelle Objekt-Modell nicht unerwünscht nennen, sondern nur nicht sinnvoll erreichbar. Wenn man es einfach haben könnte, würde man es nutzen, man kann es aber leider nicht so einfach haben.
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff