Dieses Jahr auf der JAX 2015 habe ich mich für den Workshop Domain Driven Design mit Eric Evans entschieden (dem Begründer von Domain Driven Design). Für das Thema habe ich mich bereits 2013 interessiert und das Buch von Eric Evans zu diesem Thema gelesen.
In meinem Scrum Developer Kurs 2013 kam ich für die Vorbereitung auf die anschließende Prüfung auf eine Liste mit Büchern zum Thema Scrum, wo dieses Buch kurz vorgestellt wurde. Seit diesem Tag beschäftigt mich das Thema. Daher wollte ich diesen Workshop keinesfalls verpassen.
Der Workshop war unterteilt in einen Vormittags Teil und einen Nachmittags Teil. Am Vormittag ging es um die “Ubiquitous Language” und um Models. Darum, dass ein Model nicht zwingend der Realität entsprechen muss, sondern primär helfen soll eine Vorstellung vom Problem zu bekommen und einer damit einhergehenden Lösung.
Eine Frage die hierbei aufkam war unter anderem die nach dem zu verwendenden Sprachgebrauch beim Entwickeln. Soll man nun - da Quellcode in Englisch geschrieben wird - die Begriffe in’s Englische übersetzen oder doch lieber in der eigenen Sprache belassen? Es gibt hierzu verschiedene Ansätze. Der Einfachste wäre, ein internationales Unternehmen entscheidet sich aufgrund seiner internationalen Stellung dazu vollständig im Englischen zu bleiben. Ein anderer Ansatz, besteht darin die Schlüsselbegriffe, welche die Problem-Domäne ausmachen, in der eigenen Landessprache zu benutzen, da bei einer Übersetzung der Context möglicherweise verloren geht, bzw. eine andere Bedeutung bekommen würde. Es gibt hier jedoch keine abschließend allgemein gültige Meinung.
Wir haben uns dann noch mit sogenannten Code-Proben, also mit dem Ausprobieren von möglichen Refactorings beschäftigt. Hierbei geht es darum, das ein Entwicklerpaar oder eine eine kleine Gruppe, ähnlich den Kundschaftern beim Auskunschaften möglicher Wege/Routen, neue Model-Lösungen evaluiert. Das kann z.B. in einem eigenen “Branch” erfolgen. Man schaut dann einfach ob das Model besser arbeitet oder aber eben auch nicht. Hierbei soll man auch darauf achten, nicht nur die “Gutartigen” Fälle (“happy path”) zu betrachten, sondern auch “Fehlerfälle” gezielt mit einplanen - meist über “Assertions oder “Requires” realisiert. Mit einem Domänenexperten über die Dinge zu sprechen, die ihn beunruhigen, liefert Hinweise worauf man besonders achten sollte.
Im laufe des späten Vormittags haben wir dann noch über die “Bounded Contexts” gesprochen. Es wird zwangsläufig dazu kommen, das ein Model für ein bestimmtes Problem sehr gut funktioniert, dafür aber ein anderes Problem nur unzureichend löst. Was tun? Refaktorisieren? Neues Model finden? - Das Beste ist es hier, einen neuen Kontext aufzumachen und damit ein neues Model für das neue Problemfeld zu finden und über Bounded Contexts mit eigenständigen Modellen zu arbeiten.
Der Nachmittag beschäftigte sich mit “Strategischem Design”. Im wesentlichen geht es hierbei darum, wie man die Abgrenzung zwischen verschiedenen Bounded Contexts am Besten bewerkstelligen kann.
Bei der Abgrenzung eines Bounded Contexts geht es auch darum, die unterschiedlichen Models, welche innerhalb eines Bounded Context verwendet werden, auf den jeweils anderen Context zu “mappen”. Hierfür wird eine “Context-Map” verwendet.
Wie diese Context-Map dann umgesetzt wird ergibt sich aus der Enge der Zusammenarbeit der anderen Bounded Contexts.
Eric hat hierfür die folgenden Strategien entwickelt:
- Partnership
- Shared Kernel
- Customer Supplier
- Conformist
- Anti-Corruption Layer
- Open-Host Service
- Published Language
- Separate Ways
- Big Ball of Mud
Eine Referenz der Begriffe und Strategien findet sich unter der Creative Commons Lizenz auf der domainlanguage.com Website.