J and I and Me
2007-06-21
  Spring One: Keynote Eric Evans
Eric Evans sprach dann über Making Models Matter. Eric hat den modernen Klassiker "Domain Driven Design" geschrieben.

Ein Modell ist nicht ein UML-Diagramme oder Teile des Codes. Es ist abstrakter. So kann man zum Beisplel eine alte Karte als ein geographisches Modell sehen - die alte chinesische Karte zeigt China in der Mitte und andere Plätze sind nur wenig detailiert und kleiner dargestellt. Auf einer modernen Karte sind dide Größen richtig, aber eine amerikanische Karte hat trotzdem die USA in der Mitte. Aber auch die Karte ist verzerrt: Grönland ist zum Beispiel zu groß (Mercator-Projektion), aber eine gerade Linie ist auch in der Realität eine gerade Linie, so dass es für Schiffs-Navigation günstig ist.

Ein Modell ist also ein System von Abstraktionen, die ausgewählte Aspekte einer Domain beschreiben und benutzt werden kann, um Probleme in dieser Domäne zu lösen. Darauf basierte eine ubiquitäre Sprache: Eine Sprache, die sich am Domänen-Modell orientiert und von allen Team-Mitgliedern benutzt wird, um die Aktivitäten der Mitarbeiter mit der Software zu verbinden.

Eric plädiert dafür, sich auf die Kern-Domäne zu fokussieren. Sie ist der Teil, der überhaupt dazu führt, dass man das System schreiben will. Die Kern-Domäne ist dann auch meistens der Grund, warum man die Anwendung nicht einfach kauft oder outsourct. Es ist eine Anwendung der 80-20-Regel: 80% des Werts kommen von 20% des Systems (oder sogar weniger).

Er berichtete dann aus einem Projekt: Zwei Systeme erbrachten die Supply Chain und die Anwwendungen wurden immer mehr miteinanderer verwoben. Neue Features sind schwierig. Ein Plan des Kunden war es, das System durch ein sauber System zu implementieren. Dazu solle in 3 Jahren abgelöst werden. Im ersten Jahr sollen die generischen Funktionen gebaut weden, dann die Legacy abgelöst werden und dann im dritten Jahr sollte es neue Feature geben. Erics Vorhersage war, dass im zweiten Jahr Dinge problematisch werden, weil das neue System schwierig abzulösen sein wird, weil es eben gewachsene Lösungen enthält. Außerdem wird es während der Ablösung weiterentwickelt, wodurch die Komplexität noch schwieriger wird. Dadurch wird die Anwendung nur eine Portierung der alten Anwendung, weil der Stress zunimmt und man die alte Funktionalitäten nicht sauber implementierne kann. Zudem wird das System sehr teuer sein und keine neuen Funktionalitäten haben - was politisch schwer zu verkaufen ist.

Die Firma will eigentlich die neuen tollen Features aus Jahr 3, was als letztes implementiert wird. Also: Man baut diese Sachen direkt in das alte System ein. Dadurch kann man die neuen Features während der Projektlaufzeit in das System einbauen und die Features aus Jahr 3 direkt umsetzten. Man muss dabei Teile der alten Anwendung refactoren, um das System passend erweitern zu können. Das kann dann aber auch in einen Hack ausarten, in dem man dann einfach nur die neuen Funktionalitäten "irgendwo" implementiert. Und das ist, was dann häufig einfach gemacht wird. Das geht aber nur bis zu einem gewissen Maße, bis man die Software nicht mehr wirklch ändern kann. Das Problem ist, dass viele Entwickler Dinge aufräumen wollen. Dadurch werden die Hacker, die sich auf die Kern-Domäne fokussieren, belohnt, weil sie mit der sauberen Infrasttuktur produktiver werden und gleichzeitig auf dieser Infrastruktur nicht besonders saubere Anwendungen bauen, dadurch die Infrastruktur "verschmutzen" und gleichzeitig den meisten Geschäftsnutzen erzeugen.

Also: Nicht alle große Systeme werden sauber designt sein. Das ist eine schlichte Realität - man muss lernen, sie zu akzeptieren. Also: Was soll man sauber designen? Natürlich die Kern-Domäne.

Und: Es gibt immer mehrere Modelle. Er führte dann den Begriff des Kontext ein: Das ist die Umgebung, in der ein Wort oder eine Aussage eine Bedeutung bekommt. Also macht ein Modell nur in seinem Kontext Sinn und man kann Dinge von einem Kontext in einen anderen übersetzen. (Context Map) Man kann eine Darstellung des Models von einer anderen Darstellung des Models entkoppeln, indem man einen Anti-Corruption-Layer einzieht, der das eigene System von der Darstellung in den anderen Systemen entkoppelt.

Zurück zu dem 3-Jahre-Projekt: Man baut also primär die neuen Features und baut eine kleine Infrastruktur, um das zu unerstützen und löst das Legacy-System nicht ab. Das Legacy-System wird durch einen Anti-Corruption-Layer abgekoppelt, das übrigens aufwändiger zu implementieren sein kann, als die eigentlichen Features. Der Aufwand ist dann aber immer noch geringer als bei den anderen Lösungen. Und man bekommt dadurch auch eine Antwort auf das Problem, dass Präzisions-Designs zerbrechlich sind - man muss sie durch die Anti-Corruption-Layer "sauber" halten.

Labels: , ,

 
Bookmark and Share
Comments: 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