Begrenzte Kontexte im domänengesteuerten Design

Question

Nehmen wir an, wir befinden uns in einem Unternehmen, das Kaffeetassen verkauft und einen domänengesteuerten Designansatz für seine Architekturanforderungen bietet.

Gemäß den gängigen DDD-Praktiken (dh in der Literatur von Vaughn Vernon und Eric Evans, die in diesem Medium-Artikel gut zusammengefasst sind ) besteht ein guter Ausgangspunkt darin, Kerndomänen, generische Domänen, unterstützende Domänen und begrenzte Kontexte zu identifizieren. Dann können die Domänen in die begrenzten Kontexte passen. Eine Domain kann in mehr als einem Kontext mit unterschiedlicher Bedeutung (aufgrund unterschiedlichen Kontexts ) angezeigt werden .

Nach meinem Verständnis können gebundene Kontexte auf wichtige Geschäftsbereiche abgebildet werden (nicht unbedingt mit realen Abteilungen in der Organisation übereinstimmen, aber das ist ein anderes Thema).

Nehmen wir also an, wir haben diese Geschäftsbereiche identifiziert

• Anbieter
• Versand
• Zahlung
• Lieferung
• Texterkennung

Konzentrieren wir uns auf diesen letzten. Einer der wichtigsten Teile im Geschäft ist die Texterkennung. Der Kunde lädt ein Bild hoch, damit es auf die Tasse gedruckt werden kann, und das Backend führt die Texterkennung durch, um zusätzliche Funktionen basierend auf dem gefundenen Text anzubieten, z. B. Speichern des Designs, Markieren für das Teilen der Designs in SNs mit einem Hashtag, Analyse. .. demnächst. Angenommen, diese Texterkennung wird durch eine externe Lösung wie Cloudvision von Google erreicht.

Die Frage, die ich hier aufgeworfen habe, ist, dass die Texterkennung für mich eher eine technische Lösung als ein begrenzter Kontext selbst ist. Der andere Denkstrom, den wir haben, ist, dass er als begrenzter Kontext reflektiert werden sollte.

Was denken Sie?

Es ist wahr, dass es sich um eine "externe" Lösung handelt, daher sollte sie sich in gewisser Weise in einem der üblichen DDD-Diagramme widerspiegeln. Aber ich denke, es passt besser als generische Domäne, nicht als begrenzter Kontext, und wird im Kontextzuordnungsdiagramm (das Domänen enthält) angezeigt.

Ein weiteres Thema, das helfen könnte, ist Strategic vs Tactical DDD. Ich habe noch kein richtiges Verständnis von Tactical DDD. Für mich haben Anbieter-, Versand-, Zahlungs- und Lieferkontexte in einem strategischen DDD Sinn. Aber die Texterkennung sollte dort nicht gemischt werden, sie hat für mich eine "taktischere" Bedeutung.

EDIT: Zur Klärung der Frage von @Ewan Spricht das Unternehmen über Texterkennung als Teil des Geschäftsprozesses? Nicht definitiv. Das Geschäft spricht nicht von "Texterkennung". Es ist kein Softwareunternehmen. Der Begriff wird nur auf der darin enthaltenen technischen Ebene behandelt.

Könnten Sie noch andere Punkte hinzufügen, an die ich nicht gedacht habe? Haben Sie eine andere Meinung dazu?

Ich schätze es sehr.

Answer 1

Ich denke, die zugrunde liegende Frage lautet: "Was ist ein begrenzter Kontext für Sie?" .

Aus der Modellierung Sicht ist die Texterkennung Bibliothek oder Komponente ein anderes Modell daher ein separater beschränkter Kontext sein sollte. Es ist unglaublich einfach, wenn Sie es nur auf Papier zeichnen: Sie möchten nicht, dass die Interna der Texterkennung in andere Modelle gelangen und umgekehrt.

Was die Dinge normalerweise kompliziert macht, ist "Also, was soll ich auf Codeebene tun?" In diesem Fall könnte dies Folgendes bedeuten: Stellen Sie sicher, dass Sie keine starke Kopplung an einen externen Anbieter wünschen und dass Sie die Client-Schnittstelle, die Ihr Modell benötigt, von der extern bereitgestellten Schnittstelle trennen, die das Tool bietet .

PLUS: Begrenzte Kontexte existieren im Lösungsraum, Domänen existieren im Problemraum. Hier gibt es zwei verschiedene Argumentationsweisen.

Answer 2

Um den Artikel zu zitieren, auf den Sie verweisen:

Ein begrenzter Kontext definiert die Grenzen der Anwendbarkeit für eine allgegenwärtige Sprache

Wenn Sie sich Ihre Beispiele ansehen, haben Sie wahrscheinlich nur einen einzigen begrenzten Kontext, in dem Bestellung, Zahlung, Lieferung usw. jeweils eine einzige Bedeutung und ein einziges Objekt haben.

Sie können einen Ihrer Geschäftsbereiche auswählen und ihn als begrenzten Kontext bezeichnen. Wenn Sie jedoch keinen Begriff wiederverwenden, hat beispielsweise die Zahlung im Geschäftsbereich des Anbieters eine völlig andere Bedeutung als die Zahlung im Geschäftsbereich "Zahlung" einen Unterschied machen.

Es ist unwahrscheinlich, dass eine Texterkennungsbibliothek einen Ihrer Geschäftsbegriffe verwendet. Vielleicht haben Sie einen Prozess mit Bestellung, bei dem die automatisierte Erkennung versucht wird und wenn nicht mit hoher Sicherheit ein menschlicher Prozess verwendet wird und es Begriffe in der Geschäftssprache gibt, die sich überschneiden?

Wo Sie die Namen der Dinge auswählen können, ist es am besten, in einem einzigen begrenzten Kontext zu bleiben und einfach die Namen zu ändern.