Das SaaS für Trainer ist zu groß als dass ich es ohne weitere innere Struktur bauen würde. In der dritten Folge meines wöchentlichen Devlogs beschreibe ich, wie ich zu abgegrenzten Bereichen in der Domäne kam und somit zu den top-level Subsystemen in der fachlichen Architektur.
Bounded Contexts finden
Ein Stift ist deine Antenne ins Universum.
(Mein früherer Yogalehrer)
Obwohl ich vorige Woche meine User Story Map mit Hilfe eines Tools erstellt habe, wollte ich die Inspiration, die ich durch einen Stift in meiner Hand bekomme, nicht missen. Ich habe mir also ganz old-school-mäßig die Map ausgedruckt und mit einem Stift die Bereiche eingezeichnet, in denen "eine eigene Sprache gesprochen" wird:
Die eingezeichneten Bereiche sehe ich als bounded contexts im Sinne von Domain-Driven Design, denn es wird über ganz separate Themen gesprochen, die man in getrennten Teilmodellen darstellen kann.
bounded context
A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
(Eric Evans)
User(s)
(Der Stift im Video zögert, ob er das "s" noch anhängen soll oder nicht. Vielleicht hätte ich es tun sollen.) In diesem Bereich wird über Benutzer gesprochen, die sich registrieren, sich einloggen, ihre Profile bearbeiten und unglücklicherweise eines Tages ihren Account auch wieder schließen werden. Diese Sprache hat nichts zu tun mit Trainings – sie könnte für jedes beliebige System gelten.
Material
In diesem Bereich der Map arbeitet ein Trainer ganz intensiv und konzentriert mit Materialien, die ihm zur Verfügung stehen (eine typische System-2-Tätigkeit). Rohmaterial ist der Ausgangspunkt, und Lernziele sind der gewünschte Endpunkt. Dieses Thema hat nichts mit User-Verwaltung und (noch) nichts mit dem Erstellen der tatsächlichen Trainingsstruktur zu tun.
Training
Hier versucht der Trainer, die vielen Konzepte, die er im Rohmaterial fand und die Lernziele, die er sich daraus gebildet hat, in eine ganz neue Struktur zu bringen, eben die Struktur seines Trainings, das aus Modulen und Lerneinheiten besteht. Er wird zwar die Sprache des Materials nutzen, doch eher einseitig: Material braucht nichts von Training zu wissen, doch sollten Lerneinheiten (unit) am besten zu Lernzielen (learning goal) führen. Eine unit aus dem Kontext Training ist jedoch in der Sprache von Material gesprochen einfach nur eine note. Erst der geschriebene Inhalt der note macht die note zu einem learning goal.
Management
Ein Trainer wird seine trainings eines Tages verwalten müssen. Wenn sie/er zum Beispiel eine Vorlesungsreihe, die ein ganzes Semester lang gehen soll, im Zusammenhang betrachten möchte, wäre es doch nett, wenn die Vorlesungsreihe als project dargestellt würde. Richtig komplizierte Trainings wird er vielleicht nicht allein, sondern mit Kolleg/inn/en gemeinsam entwerfen wollen, also im team. projects und teams klingen nach Management und könnten eigentlich etwas Beliebiges erstellen, nicht nur Trainings. Also ist auch management eine separate Sprache, die aus einem eigenen bounded context im Sinne von Domain-Driven Design kommt.
Gemeinsames Liefern
Wenn ich das SaaS nicht allein, sondern mit mehreren Entwicklungsteams bauen würde, dann gäbe ich jeden bounded context in die Hände eines Teams. Das würde dazu führen, dass diese Teams eines Tages gemeinsam das gesamte SaaS abliefern müssen.
Dabei spielt es jedoch eine Rolle, wer seine Ergebnisse schon einmal erfolgreich abliefern kann, ohne auf andere angewiesen zu sein:
The upstream team may succeed independently of the fate of the downstream team.
(Eric Evans)
Wenn ich auf meine markierten bounded contexts aus dem Video schaue, scheint es folgende Abhängigkeiten zu geben:
- users scheint mir zunächst free, jedoch später upstream
- material scheint mir ebenfalls zunächst free, jedoch später upstream
- training scheint mir downstream von material
- management scheint mir downstream von users und von training
free
A software development context in which the direction, success or failure of development work in other contexts has little effect on delivery.
(Eric Evans)
Grafisch erkennt man das natürlich besser, also zeichne ich noch schnell eine Context Map:
Die Liste der Kontexte ist bestimmt noch nicht komplett, aber es reicht um zu starten. Ich bin gespannt, wann sich die Notwendigkeit weiterer Kontexte zeigen wird und ob ich sie dann so locker einfügen kann wie ich jetzt vermute.
Fachliche Subsysteme
Obwohl das nicht immer so sein muss, würde ich die top-level Subsysteme der fachlichen Architektur diesmal genauso schneiden wie die bounded contexts. Weil es so wenige Kontexte sind, die Themen sich wirklich sehr unterschiedlich anhören, und weil ich der einzige sein werde, der hier entwickelt, verwende ich diesmal dafür nicht viel Zeit zum Nachdenken. Der Code wird mir schon zeigen, ob ich richtig lag oder falsch.
In einer größeren Organisation empfehle ich jedoch, über die bounded contexts explizit zu diskutieren, damit alle ein gemeinsam getragenes Verständnis davon haben. Außerdem entsteht daraus ja etwas sehr Wichtiges: Teamgrenzen. Nichts ist schlimmer als wenn später jemand kommt und sagt "Das habt Ihr ja einfach so entschieden, ohne mich zu fragen, ich fand das ja schon immer komisch geschnitten."
Nächste Schritte
O.K., also habe ich jetzt einen guten Eindruck von der initial benötigten Komplexität meines Vorhabens. Die Qualitäten hatte ich ja vorige Woche schon aufgesammelt, also sollte mich jetzt eigentlich nichts mehr davon abhalten, den Technologie-Stack anzugeben. Es scheint, als käme diese Woche also mehr als eine Folge des Devlogs.
Bitte schreiben Sie Kommentare unter den Artikel – ich bin gespannt, was Sie dazu meinen.
