Get best of the week

Entwerfen eines begrenzten Kontexts mit einem Bounded Context Canvas: Workshop-Rezept

Zu den Themen der bevorstehenden TechLead Conf 2020- Konferenz gehört eine ausführliche Diskussion über Domain-Driven Design und EventStorming. Neben der Erstellung eines 2-Slot- Berichts von Konstantin Gustov über DDD , eines Berichts von Sergey Baranov über EventStorming und eines Mitaps, in dem wir ein DDD-Radar erstellen, haben wir beschlossen, einen Artikel über eine der beliebtesten Methoden zum Entwerfen eines begrenzten Kontexts zu übersetzen.

Wie kann ein großes System in kleinere, besser verwaltbare Komponenten aufgeteilt werden? Diese Frage wird mir oft gestellt, deshalb habe ich mein Wissen in diesem Artikel gesammelt.

In DDD wird ein großes System in begrenzte Kontexte zerlegt (Kommentar eines Übersetzers: im Folgenden werden sie als begrenzte Kontexte bezeichnet) , die zu natürlichen Grenzen werden - wie Mikrodienste im Code und als Teams in einer Organisation.

Es gibt keine Möglichkeit, die guten Grenzen eines begrenzten Kontexts schnell und einfach zu bestimmen. Dies erfordert umfassende und gründliche Kenntnisse des Geschäfts und des Fachgebiets. Dieses Workshop-Format wurde entwickelt, um diese beiden Anforderungen zu erfüllen, und verwendet zwei Tools, um das effektivste Systemdesign zu finden: EventStorming und Bounded Context Canvas.

Bild

„Ich habe diese Leinwand im Rahmen der Durchführung von DDD-Workshops bei öffentlichen Veranstaltungen und Unternehmenssitzungen entwickelt. Sie können die Struktur jederzeit ändern, wenn Sie Formate finden, die für Sie am besten geeignet sind. “

Rezept


Das Hauptrezept besteht aus Folgendem:

  1. EventStorming (mindestens 1 Stunde).
  2. Modellierung von Kandidaten für einen begrenzten Kontext (mindestens 30 Minuten).
  3. Modellierung des Flusses von Domänennachrichten (mindestens 30 Minuten).
  4. Bounded Context Canvas (mindestens 90 Minuten).
  5. Erstellen von Kontextkarten (mindestens 45 Minuten).

Als Ausgangspunkt empfehle ich, einen ganzen Tag für diesen Workshop vorzusehen. Dies hilft Ihnen zu verstehen, wie viel Zeit Sie wirklich benötigen, um den Workshop korrekt durchzuführen. Wenn es teuer (zeitaufwändig) ist, alle zusammenzubringen, versuchen Sie, sofort zwei Tage einzuplanen, um alles zu erledigen.

Im Idealfall sollten die Teilnehmer Fachexperten und technische Experten sein. Wenn dies schwierig zu organisieren ist, versuchen Sie sicherzustellen, dass Domain-Experten mindestens die erste Stunde am Workshop teilnehmen.

Grundprinzipien der Modellierung


Um eine Sitzung mit Experten durchzuführen, benötigen Sie einen geräumigen Raum. Wenn Sie sich für ein kleines Publikum entscheiden, werden Sie höchstwahrscheinlich von den Ergebnissen enttäuscht sein. Jede Gruppe von 4 Personen benötigt mindestens 4 Meter an der Wand.

Ich werde meine Methodik in freier Form ohne strenge Vorschriften beschreiben. Beachten Sie jedoch:
„Wir wechseln ständig zwischen dem Problemraum und dem Lösungsraum. "Wir suchen nach Informationen, erstellen ein Modell, suchen nach zusätzlichen Informationen, aktualisieren das Modell usw."
Und noch ein wichtiger Punkt: Der Zweck der Sitzung besteht darin, Optionen zu entwickeln und die Fähigkeit zu entwickeln, in Zukunft bessere Optionen anzubieten.

1. EventStorming


Um ein System zu entwerfen, benötigen Sie zwei Dinge: eine ausreichend gute allgemeine Vorstellung des gesamten Systems und ein ziemlich tiefes Verständnis der Details in jedem Bereich. Beginnen wir dazu mit EventStorming .

EventStorming ist eine kollaborative Entwurfsmethode, mit der Sie einen großen Problembereich von Anfang bis Ende simulieren und bei Bedarf eine große Anzahl von Details aufschlüsseln können.

Bild

Wenn Sie dies zum ersten Mal tun, empfehle ich Ihnen, 1-2 Stunden für EventStorming vorzusehen. Nach Abschluss von EventStorming empfehle ich, sich in Gruppen von 4 Personen aufzuteilen.
Auf der TechLead Conf 2020 wird Sergey Baranov über praktische Erfahrungen mit EventStorming sprechen .

2. Suchen Sie nach Kandidaten für einen begrenzten Kontext


Nachdem Ihre Domain in EventStorming umfassend und umfassend modelliert wurde, können Sie beginnen, Fragmente in einem begrenzten Kontext zu gruppieren und zusammenzuführen.

Bild

Es gibt viele Methoden zur Bestimmung des begrenzten Kontexts. Ich empfehle, mit folgendem zu beginnen:

  • Beginnen Sie mit dem Wert - identifizieren Sie die Kernteile der Domäne, die für das Unternehmen am wertvollsten sind.
  • Beginnen Sie mit einem einfachen Modell - erstellen Sie ein naives Modell, indem Sie die Zeitachse in aufeinanderfolgende Schritte unterteilen.
  • Suchen Sie nach Schlüsselereignissen - Geschäftsereignissen, die sich auf verschiedene Teile des Geschäftsprozesses auswirken.

Nehmen Sie sich zum ersten Mal nicht mehr als 30 Minuten Zeit für diese Aufgabe. Bitten Sie die Gruppe, das ursprüngliche Modell mit begrenztem Kontext als Ausgangspunkt zu erstellen. Es muss nicht perfekt sein und ist wahrscheinlich nicht die endgültige Lösung.

Die Ausgabe sollte in einer Liste begrenzter Kontextnamen auf einem Flipchart oder Papier erfolgen. Sie können EventStorming nicht physisch ändern, wenn Sie mehrere Gruppen haben.

Nächste Schritte


Möglicherweise sehen Sie sofort verschiedene Möglichkeiten, das System zu modellieren. Wählen Sie zunächst eines davon für die Arbeit aus und schreiben Sie andere mögliche Modelle auf (sie werden später nützlich sein). Sie können auch verstehen, dass Ihnen Domain-Informationen fehlen. Wenn ja, führen Sie eine weitere Runde EventStorming durch.

3. Modellierung des Domänennachrichtenflusses


Eine Möglichkeit, Ihr Design zu validieren und nach Verbesserungspunkten zu suchen, besteht darin, das Zusammenspiel begrenzter Kontexte in vollständigen Geschäftssystemszenarien zu visualisieren.

Wenn sich der Domänenfluss als komplex herausstellt, mit einer großen Anzahl von Abhängigkeiten und bidirektionalen Verbindungen, ist Ihr Design fragil und muss weiter analysiert werden.

Es gibt viele Visualisierungsmethoden, die zum Modellieren von Flüssen und Anwendungsfällen verwendet werden können, einschließlich UML-Sequenzdiagrammen und UML-Anwendungsfalldiagrammen. Ich empfehle die Domain Storytelling Option .

Bei der Modellierung des Nachrichtenflusses einer Subjektdomäne sind begrenzte Kontexte die Akteure in der Geschichte. Eine typische Geschichte beginnt also damit, dass der Benutzer versucht, ein bestimmtes Ziel zu erreichen, und die Interaktion zwischen begrenzten Kontexten zielt darauf ab, dem Benutzer eine Lösung zu bieten.

Bild
Ein fiktives Beispiel für einen Domänennachrichtenfluss Durch die

Modellierung strategischer Domänenflüsse erhalten Sie Feedback zu den vorgeschlagenen begrenzten Kontexten. Es zeigt, wie Kontexte miteinander zusammenarbeiten und voneinander abhängen, um einen vollständigen Geschäftsprozess abzuschließen. Dies kann helfen, ein alternatives Design zu finden.

Die Frage, die Sie sich stellen sollten, ist, ob die Beschreibung jedes begrenzten Kontexts mit der Rolle übereinstimmt, die er im Domänenstrom spielt. Wenn nicht, müssen die Namen- oder Kontextgrenzen wahrscheinlich neu gestaltet werden.

Nächste Schritte


Da Ihre Domain-Flows die Beziehung zwischen begrenzten Kontexten bestimmen, können Sie offensichtliche Designfehler sofort erkennen. Sie können zur vorherigen Aktion zurückkehren und die Kandidaten für einen begrenzten Kontext aktualisieren oder eine zweite Iteration von EventStorming durchführen. Sie können auch Ihre Gedanken zum Design aufschreiben und weitere Informationen zu den nächsten Schritten sammeln, bevor Sie mit dem Redesign beginnen.

4. Bounded Contexts Canvas


Die nächste Entwurfsphase ist die Entwicklung von Kandidaten für einen begrenzten Kontext unter Verwendung von Details der wichtigsten Entwurfskriterien. Ihr Team sollte den begrenzten Kontext auswählen, den Sie für am wichtigsten halten. Beschränken Sie die Diskussion auf maximal 3 Minuten. Es ist nicht kritisch, 100% genau zu sein.

Zeichnen Sie nun einen Bounded Context Canvas und führen Sie die folgenden Schritte aus, um die Details einzugeben. Ich empfehle 1 Blatt Flipchart oder Papier der gleichen Größe.
Wiederholen Sie den Vorgang nach Abschluss dieser Schritte, bis Sie alle Ihre begrenzten Kontexte identifiziert haben. Versuchen Sie, Ihre Zeit gleichmäßig auf die identifizierten Kandidaten für den begrenzten Kontext aufzuteilen.

4.1 Definition des allgemeinen Kontextes


Definieren Sie zunächst den Namen Ihres begrenzten Kontexts und dessen Beschreibung. Die Beschreibung sollte den Zweck des Kontexts in der Domäne und seine Rolle im Unternehmen und nicht die Implementierungsdetails enthalten.

Als nächstes müssen Sie eine strategische Klassifizierung vornehmen. Ist der begrenzte Kontext der Hauptteil des Systems, ein Hilfselement, ein gemeinsames oder etwas anderes? Lesen Sie den Beitrag von Vlad, wenn Sie Hilfe bei der Auswahl benötigen.

Bild
Als Beispiel ein gefüllter Bounded Context Canvas nach dem ersten Schritt.

Nächste Schritte


Wenn Sie keinen eindeutigen Namen finden oder keine zusammenhängende, genaue Beschreibung schreiben können oder Ihre Begriffe für Ubiquitous Language (UL) nicht eindeutig sind, betrachten Sie dies als Feedback für Ihr Design. Überlegen Sie, ob Sie die Ränder neu gestalten möchten, oder machen Sie sich eine Notiz und kommen Sie später wieder (normalerweise ist es besser, später wiederzukommen).

4.2 Klärung der Geschäftsregeln und Bildung einer gemeinsamen Sprache


Kehren Sie nun zu EventStorming zurück und sehen Sie sich die Notizen für diesen begrenzten Kontext an. Suchen Sie die wichtigsten Geschäftsregeln und -richtlinien, wählen Sie die drei wichtigsten aus und fügen Sie sie dem Arbeitsbereich hinzu.
Konstantin Gustov von TechLead Conf 2020 wird über seine langjährige Erfahrung mit Ubiquitous Language und anderen DDD-Komponenten in Raiffeisen sprechen .
Dies ist auch ein guter Zeitpunkt, um nach wichtigen Geschäftswörtern oder -phrasen zu suchen, um sie der Leinwand im Abschnitt Ubiquitous Language hinzuzufügen. Sie werden während des gesamten Workshops weiterhin Wörter und Sätze hinzufügen, dies ist nur der Ausgangspunkt.

Bild

4.3 Funktionsanalyse


Der nächste Schritt besteht darin, die Möglichkeiten zu untersuchen, die der begrenzte Kontext bietet. Dies verdeutlicht nicht nur, was er tut, sondern gibt auch viel Feedback für das Design. Sie können Fragen stellen wie:

  • Ist dieser Kontext mit Verantwortlichkeiten überladen?
  • Sehen Chancen verwandt aus?
  • Stimmen die Funktionen mit dem Namen und der Beschreibung des Kontexts überein?
  • Was ist, wenn wir diese Gelegenheit aus dem Zusammenhang ziehen?

Definieren Sie Opportunities, indem Sie eine öffentliche Schnittstelle einführen. Was können Verbraucher in diesem begrenzten Kontext anfordern und welche Befehle können sie aufrufen? Verwenden Sie Domänendatenströme, um zu sehen, was Verbraucher in diesem begrenzten Kontext benötigen.

Nicht alle Funktionen werden durch Befehle und Anforderungen von außen aktiviert. Einige Funktionen können von innen gestartet werden. Zum Beispiel geplante Aufgaben. Manchmal stellen Sie möglicherweise fest, dass Opportunities gruppiert sind, z. B. ein Befehl, eine Anforderung und eine Benachrichtigung. Wenn ja, fügen Sie sie auf der Leinwand zusammen und geben Sie dem Cluster einen Namen.

Möglicherweise haben Sie das Gefühl, dass Verantwortung unangemessen ist und sich auf einen anderen begrenzten Kontext beziehen sollte. Wenn ja, wählen Sie es mit einem Erkennungszeichen auf dem Aufkleber aus.

Bild

Nächste Schritte


Wenn Sie Schwierigkeiten haben, die Kontextfunktionen zu bestimmen, oder das Gefühl haben, dass einige von ihnen fehlen, empfehle ich, zu EventStorming zurückzukehren und diesen begrenzten Kontext detaillierter zu modellieren, wobei Sie sich darauf konzentrieren, die für andere Kontexte oder Dienste erforderlichen Funktionen zu finden.

Vertiefungsmöglichkeiten [optional]


Legen Sie jede Gelegenheit auf Ihrer Leinwand für zusätzliche Funktionen fest. Dieses zusätzliche Detail hilft Ihnen bei der Suche nach alternativen Modellen. Wenn auf der Leinwand nicht genügend Platz für Teile vorhanden ist, suchen Sie ein anderes Blatt Papier oder Platz an der Wand. Sie können so viele Schichten tiefer gehen, wie Sie für richtig halten.

4.4 Abhängigkeiten


Abhängigkeiten sind notwendig, wenn wir Modularität wollen, aber sie verursachen auch eine Vielzahl von geschäftlichen, technischen und sozialen Problemen. Daher ist es wichtig, die Abhängigkeiten zu erkennen, ihren Einfluss zu verstehen und alternative Optionen in Betracht zu ziehen. Der letzte Schritt beim Entwerfen eines begrenzten Kontexts besteht darin, sicherzustellen, dass Sie alle wichtigen Abhängigkeiten Ihres begrenzten Kontexts erfassen.

Identifizieren Sie in den EventStorming-Ergebnis- und Domänenflussdiagrammen jede Abhängigkeit mit einem begrenzten Kontext und notieren Sie die folgenden Informationen:

  • den Namen eines anderen begrenzten Kontexts oder Dienstes;
  • Eine kurze Erklärung, warum Sucht besteht
  • Wo ist die Abhängigkeit: innerhalb dieses Systems oder in einem externen System (z. B. einem Drittanbieter-Dienst);
  • Beziehungstyp: Dies ist eine eingehende Abhängigkeit (ein anderer Dienst hängt von diesem begrenzten Kontext ab), eine ausgehende (dieser begrenzte Kontext hängt von einem anderen ab), eine bidirektionale oder eine Benutzeroberfläche (die Abhängigkeit ist eine Art von Benutzeroberfläche).

Stellen Sie jede der Abhängigkeiten in Frage: ob sie benötigt wird, welche Kosten und welche Vorteile hat ihre Verfügbarkeit? Wenn Sie darauf verzichten können, markieren Sie die Abhängigkeit mit einem gelben Aufkleber.

Bild

4.5 Konstruktive Kritik


Wenn Sie die Leinwand vollständig ausgefüllt haben, nehmen Sie sich einige Minuten Zeit, um das resultierende Design Ihres begrenzten Kontexts kritisch zu bewerten. Teilen Sie Ihre Bewertungen in die folgenden Kategorien ein:

  • Gut : Designaspekte, die Sie mögen.
  • Schlecht : Designaspekte, die Sie nicht mögen.
  • Unsicher : Designaspekte, bei denen Sie sich nicht sicher sind.

4.6. Reflexion und Wiederholung


Gutes Design ist iterativ. Bevor Sie zum nächsten begrenzten Kontext übergehen, treten Sie zurück und betrachten Sie das Gesamtbild. Haben Sie etwas gelernt, das Ihrem Design widerspricht? Wenn ja, streichen Sie die vorgeschlagenen Grenzen durch und entwerfen Sie dann den nächsten begrenzten Kontext weiter.

Fragen Sie sich an dieser Stelle, ob die Domain ausreichend detailliert modelliert ist. War es schwierig, einige Teile der Leinwand zu füllen? Versuchen Sie in diesem Fall eine weitere Runde EventStorming in der gesamten Domäne oder in einigen Teilen davon.

5. Erstellen von Kontextkarten


Nachdem Sie für jeden begrenzten Kontext eine Zeichenfläche erstellt und Design-Feedback gesammelt haben, ist der nächste Teil der Sitzung eine Rückkehr zur Erkundung. Dieses Mal verfügen Sie über umfassende Kenntnisse, mit denen Sie die besten Gestaltungsmöglichkeiten finden können.

Das Ergebnis dieser Übung ist eine Sammlung grundlegender Kontextzuordnungen - Visualisierungen der strukturellen Beziehungen zwischen begrenzten Kontexten und anderen Diagrammen, die Sie für erforderlich halten, z. B. Domänenflussdiagramme. Jedes Team muss mindestens 3 Kontextkarten entwickeln, von denen jede mögliche Optionen für den Aufbau des Systems aufzeigt.

Bild
Ein Beispiel für eine sehr genaue Kontextkarte, für diesen Workshop reicht es aus.

Wir werden auf der TechLead Conf 2020 einen Mitap abhalten, bei dem wir die verschiedenen Techniken, Muster und Anti-Muster von DDD analysieren und ein visuelles Radar sammeln. Welches wird nach der Konferenz veröffentlicht.
Die endgültige Tätigkeit kann in freier Form durchgeführt werden. Ziel ist es, die gesammelten Informationen zu überprüfen und daraus eine Reihe von Systemdesigns zu entwickeln. Als Ausgangspunkt empfehle ich:

  • Zeigen Sie alle für jeden Kontext gesammelten Bewertungen an und experimentieren Sie mit "schlechten" und "unsicheren" Bewertungen.
  • Stellen Sie "Was wäre wenn" -Fragen ...
  • "Was ist, wenn wir diese Gelegenheit auf einen anderen begrenzten Kontext übertragen?"
  • "Was ist, wenn wir diese Gelegenheit nutzen und eine der Unterfunktionen in einen anderen begrenzten Kontext verschieben?"
  • "Was ist, wenn wir den begrenzten Kontext in mehrere Kontexte aufteilen?"
  • "Was ist, wenn wir eine Gelegenheit aus jedem dieser drei Kontexte nutzen und sie in einem neuen Kontext nutzen?"
  • "Was ist, wenn wir Funktionen duplizieren, um Sucht zu beseitigen?"
  • "Was ist, wenn wir einen gemeinsamen Dienst erstellen, um Doppelarbeit in verschiedenen Kontexten zu reduzieren?"
  • "Was ist, wenn wir wirklich wichtige Gelegenheiten isolieren und den Rest an einen friedlicheren Ort in einem separaten Kontext bringen?"

Wenn Sie diese Transformationen lieber visualisieren möchten, können die folgenden Abbildungen hilfreich sein:

Bild

Bild

Bild

Werkstattschluss


Um die Sitzung abzuschließen, sollte jede Gruppe eine Auswahl der von ihnen erstellten Kontextkarten präsentieren und die Kompromisse für jedes Design erörtern. Sie müssen Ihre Wahl erklären, dazu reicht in der Regel eine Präsentation von 5-10 Minuten.

Was Sie in der Präsentation beachten müssen:

  • : .
  • : .
  • , , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

More articles:


All Articles