Was sind eigentlich Subdomains?

Beim Studium von Domain-Driven Design (DDD) bin ich auf das Konzept der Subdomain gestoßen, aber ich glaube, ich verstehe es noch nicht. Mein erstes Verständnis davon war, dass eine Subdomain eine Teilmenge der Domain der Anwendung ist. Mit anderen Worten, es ist eine Partition des Problemraums. Ich habe gelesen, dass es drei Arten von Subdomains gibt:

• Kern-Subdomänen
• unterstützende Subdomains
• generische Subdomains.

Mein Verständnis war ungefähr so: Wir wählen die Domäne der Anwendung aus, und sie ist ziemlich komplex. Dann schauen wir uns das an und finden einen Weg, es in einfachere Teile zu unterteilen, von denen einige Kern-Subdomänen und einige unterstützend wären, während andere generisch wären.

Bei der Suche nach weiteren Informationen habe ich einige Leute gefunden, die etwas anderes gesagt haben: Es gibt nur eine Kern-Subdomäne, einige generische Subdomänen und überhaupt keine unterstützende Subdomäne.

Meine Fragen sind also:

1. Was sind Subdomains, wirklich ? Ist mein erstes Verständnis das richtige oder ist es das zweite, was ich lese?
2. Wie ist diese Idee von Subdomains nützlich?
3. Was sind einige gute Kriterien zur Identifizierung von Subdomains? Was sollten wir bei der Auswahl von Subdomains beachten, um diese Idee besser nutzen zu können?

EDIT: Als ich ein bisschen mehr suchte , fand ich Folgendes:

Denken Sie an ein E-Commerce-System. Zunächst kann man erkennen, dass es sich um eine Anwendung eines Einkaufskontexts handelt. Wenn Sie genauer hinschauen, werden Sie feststellen, dass es auch andere Kontexte gibt, z. B. Inventar, Lieferung, Konten usw.

Dies ist, was ich anfangs für eine Subdomain hielt. Wir wählen eine Domain (die Einkaufsdomain) aus und unterteilen sie in einfachere Subdomains (Inventar, Lieferung, Konten usw.). Im fraglichen Text bezeichnen sie diese jedoch als Kontexte. Ist mein früheres Verständnis also nicht Subdomänen, sondern Kontexte?

Ich habe hier auf dieser Site eine Frage zum Unterschied zwischen einer Subdomain und einem begrenzten Kontext gefunden. Die Antwort besagt, dass Subdomains eine Partition des Problemraums sind, während Kontexte Partitionen des Lösungsraums sind. Die Aufteilung des Einkaufskontexts in Inventar, Lieferung, Konten usw. ist jedoch keine konzeptionelle Partition. Das heißt, ist es eher im Problemraum als im Lösungsraum?

Haftungsausschluss : Ich bin kein DDD-Experte, aber ich werde hier mein Bestes geben, um Ihre Fragen zu beantworten.

Nehmen wir als Beispiel einen Online-Buchhändler. Ein Buchverkäufer bietet an, Bücher auf seiner Website zu verkaufen, aber er druckt die Bücher nicht selbst. Stattdessen hat er eine lange Liste von "Buchlieferanten", die die Bücher drucken und an sein Lager liefern, wo er sie verpackt und an Kunden auf der ganzen Welt versendet.

Können Sie sich die Teams vorstellen, die in dieser Firma arbeiten?

1. Das Listing-Team : Das Team, das abhängig vom Lagerbestand der Lieferanten auswählt, welche Bücher auf der Website aufgelistet werden sollen.
2. Das Fulfillment-Team : verantwortlich für das Sammeln der Bestellungen von der Website und das Verwalten des Lebenszyklus der Bestellungen.
3. Das kommerzielle Team : Dies sind die Leute, die das Hinzufügen oder Entfernen von Lieferanten zum System übernehmen.
4. Das Marketing-Team : verantwortlich für die Kampagnen und Angebote.
5. Das Lagerteam : Verantwortlich für das Sammeln und Versenden von Büchern bei den Lieferanten.

Jedes Team verwendet seine eigenen Begriffe, um zu beschreiben, was es tut. Die Teams verwenden die Domain-Sprache oder die "Ubiquitous Language", wie Eric Evans es nennt. Normalerweise hat jedes Team ein anderes mentales Modell dafür, was eine Entität ist. Zum Beispiel:

Listing team: BOOK(book_id, ISBN, title, price, weight, length, width )  
Fulfillment team: BOOK(book_id, totalPrice, sold_quantity)   
Shipping team: ITEM(book_id, delivery_date) --> they refer to the book entity as "item" 

Eine Subdomain ist ein bestimmter Teil der Domain, in dem einige Benutzer eine bestimmte Ubiquitous Language verwenden. Wenn sich die Sprache ändert, ist dies ein Hinweis darauf, dass Sie in eine andere Subdomain wechseln.

Was ist, wenn zwei Teams dieselben Begriffe verwenden? Sowohl das Fulfillment- als auch das Listing-Team nennen das Buch "Buch". Sie müssen sie fragen: "Was ist ein Buch für Sie? Was sind seine Schlüsselattribute? Wie wird es verwendet?"

Antworten auf diese Frage führen zu zwei unterschiedlichen oder ähnlichen Domänenmodellen. Je größer der Unterschied zwischen den beiden Modellen ist, desto deutlicher wird, dass es sich um zwei verschiedene begrenzte Kontexte / Unterdomänen handelt. Das Gegenteil ist auch der Fall. Je ähnlicher die beiden Modelle sind, desto wahrscheinlicher ist es, dass sie Teil derselben Subdomäne sind.

Dies kann zu sehr interessanten Ergebnissen in Ihrem Modell führen. Möglicherweise stellen Sie fest, dass die Bestellungen innerhalb der Subdomain "Erfüllung" verschiedene Zustände durchlaufen (neu -> angefordert -> versendet). Möglicherweise erfordert jeder dieser Zustände eine komplexe Verwaltung und unterschiedliche Attribute, sodass Sie diese Unterdomäne in mehrere andere Unterdomänen aufteilen können.

Dies wirft die Frage auf, wie groß die Unterdomäne (n) sein sollte. Die Antwort lautet "Lassen Sie das Domain-Modell das entscheiden". Wenn Sie eine Änderung in UL und Modell feststellen, zeichnen Sie eine Grenze für diese Unterdomäne.

Denken Sie daran, dass es bei DDD nur um das Geschäft, die Menschen und die Kommunikation (en) zwischen ihnen geht. Lassen Sie das Ihr Modell fahren.