DDD serialisierter Artikel
Warum werden DDD-Anfänger sofort krank, nachdem sie es losgeworden sind Was sagt Eric Evans zur Definition des domänengesteuerten Designs Was ist der Ausdruck von Domänenwissen in einem Modell Was ist die am besten zugängliche Architektur, um mit domänengesteuertem Design zu beginnen Übersicht über die domänengetriebene + Zwiebelarchitektur

Einführung

Wir werden darüber sprechen, wie ein "Modell" im domänengetriebenen Design wahrgenommen werden kann und wie ein begrenzter Kontext erforderlich ist.

"Begrenzter Kontext" ist ein sehr wichtiger, aber schwer zu verstehender Punkt im domänengesteuerten Design. Daher werde ich versuchen, das Verständnis seiner Notwendigkeit und Definition zu erleichtern.

Was ist ein Modell?

Wir hören oft die Wörter "Modell" und "Modellierung" in der Softwareentwicklung, aber ich denke, einige Leute haben nie aufgehört und über die Definition nachgedacht.

Wenn Sie versuchen, die Definition auf Japanisch zu googeln, wird anscheinend häufig im Zusammenhang mit UML darüber gesprochen. Da es sich um ein abstraktes Wort handelt, gibt es meines Erachtens verschiedene Definitionen, aber ich werde die Definition des Artikels von Nikkei Computer zitieren.

IT-Bericht (3-minütiger Keyword-Kurs) - Modellierung

Eine Systemkonstruktionstechnik zur Visualisierung unsichtbarer Dinge wie Geschäftsablauf und Systemstruktur.
Erstellen Sie eine Draufsicht (Modell) mit Symbolen.

Das Modell ist als *** geschrieben, um zu visualisieren, was unsichtbar ist.

Ich denke, dass dies auch in einigen Kontexten richtig ist, aber wenn Sie domänengesteuert modellieren, ist es möglicherweise besser, ein wenig vorsichtig zu sein.

*** Modellierung = Keine korrekte Darstellung dessen, was sich in der realen Welt befindet ***

darüber.

Definition von Eric Evans

Schauen Sie sich die DDD-Referenz von Eric Evans an (http://domainlanguage.com/ddd/reference/).
(Was ist dieses Dokument? Was sagt Eric Evans zur Definition des domänengesteuerten Designs? Ich schrieb in dem Artikel)

model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain Eine Zusammenfassung, die einen bestimmten Aspekt des Interessengebiets darstellt und zur Lösung verwandter Probleme verwendet wird

Wichtig ist, dass das
Modell *** ausgewählte Aspekte *** darstellt und
der Zweck *** darin besteht, *** das damit verbundene Problem zu lösen *** so ist es

Die Zusammenfassung eines bestimmten Ereignisses basiert auf der Tatsache, dass es "unmöglich ist, genau darzustellen", weil es verschiedene konkrete Dinge entfernt. Was streben Sie also an, ohne auf Genauigkeit zu zielen?
Es ist ***, ob es den Zweck der Problemlösung erfüllt ***.

Ich denke, das ist ein bisschen anders als "visualisieren" in der Nuance.

Fallstudie

In Domain Driven Design (en.wikipedia) wird beispielsweise der Unterschied zwischen Entity und Value Object beschrieben. (Ich werde später einen Artikel über die Definition von Entity und ValueObject schreiben.)

Example:
Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context.
However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object. Die meisten Fluggesellschaften unterscheiden jeden Sitzplatz auf jedem Flug eindeutig. In diesem Zusammenhang ist jeder Sitz eine Einheit.
Southwest Airlines, EasyJet und Ryanair unterscheiden jedoch nicht alle Sitze und alle Sitze sind gleich. In diesem Zusammenhang ist ein Sitz ein Wertobjekt.

Wenn Sie nur die Sitze in einem Flugzeug "visualisieren" möchten, sollten sie dasselbe Modell sein, da es sich um Sitze handelt.
In diesem Fall wurde jedoch abhängig von der Servicerichtlinie des Betreiberunternehmens physisch dasselbe als Modell erkannt.

Dies bedeutet, dass jeder Problemlösungskontext den Fokusaspekt und das definierte Modell geändert hat.

Begrenzen Sie den Anwendungsbereich des Modells

Es stellt sich heraus, dass verschiedene Fluggesellschaften unterschiedliche Vorstellungen vom Modell haben können. Ist das Modell also immer innerhalb derselben Fluggesellschaft vereinheitlicht?

Selbst wenn Sie sich ein wenig vorstellen, scheinen das Team, das physisch "Sitze" erstellt, und das Team, das Reservierungen für "Sitze" verwaltet, unterschiedliche Ansichten darüber zu haben, wie das Problem der "Sitze" gelöst werden kann.

Wenn derselbe Bereich der Modellerkennung nicht universell sein kann und es sich nicht um eine Unternehmenseinheit handelt, handelt es sich dann um eine Abteilung? Mannschaft? In erster Linie kommt es auf die Person an ...?

Wenn Sie so denken, könnten Sie zu dem Schluss kommen, dass *** der Anwendungsbereich des Modells explizit definiert werden muss ***. Diese explizite Abgrenzung wird in der domänengesteuerten Designterminologie als *** gebundener Kontext *** bezeichnet.

Siehe die Definition in der DDD-Referenz von Eric Evans (http://domainlanguage.com/ddd/reference/).

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.
Begrenzter Kontext:
Eine Beschreibung der Grenzen (normalerweise Subsysteme oder die Arbeit eines bestimmten Teams), auf die ein bestimmtes Modell definiert und angewendet wird.

Domain-gesteuertes Design misst diesem begrenzten Kontext große Bedeutung bei. Wie oben erwähnt, kann kein Modell ohne diese Grenze korrekt definiert werden.

Anschließend wird definiert, wie sich die Kontexte zueinander verhalten. Das Artefakt wird als Kontextkarte bezeichnet. Dies ist die primäre Entwurfsbasis für domänengesteuertes Design.

Zusammenfassung

Wir haben das Modell als Worterkennungsübereinstimmung definiert und den verwirrenden wortgebundenen Kontext von DDD beschrieben.

Wie wird der begrenzte Kontext in Zukunft in die Implementierung einbezogen? Ich würde gerne schreiben.