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:
- Generic Subdomains, die generische Funktionalitäten wie zum Beispiel das Handling der Zeitzonen implementieren. Weil diese gut strukturierte und eine generische Implementierung in diesem Bereich auch recht spannend ist, stürzen sich oft die besten Entwickler auf dieses Thema
- Supporting Domains, die schon speziell zum Anwendungsfall gehören, aber nicht den Kern darstellen
- Core Domain: Der tatsächliche Kern der Funktionalität
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
