Ich sehe diesen Begriff sehr im Kontext der Softwarearchitektur ("Domain-Model", "Domain-Driven-Design" usw.). Ich habe es gegoogelt, aber ich bekomme Unmengen verschiedener Definitionen. Also, was ist es wirklich?

Das Wort „Domain“ im Domain Driven Design-Buch von Eric Evans hat eine bestimmte Bedeutung. Darum geht es in der Software.

Evans geht aber noch weiter. Seiner Ansicht nach gibt es Subdomains auch mit der gleichen Software. Und das ist der Teil des Buches, der sich mit „Strategic Design“ befasst.

Es gibt drei "Domänen": die Kerndomäne, die unterstützende Domäne und die generische Domäne. Manchmal bezeichnet er diese als Unterdomänen.

Evans kümmert sich auch sehr um das eigentliche Geschäft hinter der Software, und das Buch richtet sich nicht nur an Entwickler, sondern auch an Architekten und Manager, die sehen müssen, wie die Software und das Geschäft zusammenarbeiten können, und genau darum geht es ihm, wenn er über strategisches Design spricht und diese Subdomains.

Die Kerndomäne ist also der Teil der Software, der sowohl den Wettbewerbsvorteil als auch die „Existenzberechtigung“ der Software darstellt. Dies ist der Teil der Software, weshalb ein Kunde die Software im Vergleich zu einer anderen Software kauft. Normalerweise sieht Evans darin die Domäne mit dem geringsten Prozentsatz an Code. Sie können sich das als die wichtigsten 20% vorstellen. Es ist der Teil, den man nicht wirklich von der Stange kaufen kann und der möglicherweise nur ein einzelnes Modul oder eine einzelne Komponente der gesamten Software ist.

Die unterstützende Domäne ist weiterhin wichtig und kann für die Organisation eindeutig sein, ist jedoch nicht so wichtig wie die Kerndomäne. Ohne sie ist die Software nicht so wertvoll und der Kern verlässt sich darauf. Es können mehrere Module in der Software sein, die Sie selbst geschrieben haben und die wichtige, aber unterstützende Funktionen im Kern ausführen.

Die generische Domäne ist der am wenigsten benutzerdefinierte und in gewisser Weise der am wenigsten wichtige Teil der Software. Sie haben es vielleicht im eigenen Haus geschrieben, aber es ist möglicherweise effizienter, es einfach von der Stange zu kaufen oder bekannte Open-Source-Software zu verwenden. Dieser Teil des Systems ist wahrscheinlich nicht spezifisch für Ihre Gesamtdomäne. Ob Sie also ein Versandsystem für die Weiterleitung von Paketen oder ein System für die Patientenakten haben, die generische Domäne ist der Teil dieser Systeme, der allgemein und gerecht ist müssen einfach da sein, um überhaupt zu funktionieren. Dies macht wahrscheinlich den größten Teil des Systems insgesamt aus, aber nicht unbedingt.

Aus geschäftlicher Sicht ist es wichtig zu entscheiden, was Ihre Kerndomäne ist, und Ihre Entwicklungsressourcen dort zu konzentrieren. Evans hat viele Videos, insbesondere auf der InfoQ-Site, in denen er diese Konzepte ausführlicher erklärt.

Während wir in Software häufig von „der Domäne“ sprechen, ist dies bei DDD nicht so einfach, wie es scheint.

Ich sollte beachten, dass die Konzepte von DDD nicht unbedingt in der breiteren Software-Community existieren. Andere Entwickler, Autoren und Produktleute haben möglicherweise andere Ideen und Definitionen, einige subtiler und andere weniger. Selbst andere Autoren, die über DDD geschrieben haben, mögen diese Konzepte in Evans 'Buch beschönigen, aber ich bin der Meinung, dass diese Konzepte beim Schreiben und Planen eines Softwareprojekts immer noch nützlich sind.

Die Domain ist der reale Kontext, in dem Sie versuchen, ein Problem mithilfe von Software zu lösen. Jede Domain enthält Fachwissen, Vokabeln und Tools, die Teil dieser Domain sind.

Ein konkretes Beispiel für eine Domäne könnte beispielsweise "die automatisierte Bearbeitung komplizierter Teile mit einem rotierenden Hochgeschwindigkeitsfräser" sein. Das Software- und Hardwaresystem, das dies erreicht, wird als CNC- Fräsen bezeichnet .

Ein weiteres Beispiel für eine Domäne ist die Buchhaltungsabteilung eines Unternehmens.

Weiterführende Literatur
Bounded Context von Martin Fowler

Dies bedeutet einfach, in welchem ​​Problembereich Sie arbeiten. Wenn Sie beispielsweise eine E-Commerce-Website erstellen, handelt es sich bei Ihrer Domain um "E-Commerce", das die mit den Vertriebspraktiken Ihres Kunden / Unternehmens verbundenen Prozesse umfasst. Ein Domain-Modell könnte also ein Produkt, eine Rechnung oder ein Versandprotokoll darstellen.

Eine Domain ist ein Wissensgebiet. Es kann sich jedoch um eine Aktivität handeln, bei der Probleme auftreten, die durch Ihre Software gelöst wurden. ( Wiki , DDD-Community )

Eric Evans erklärt in seinem Buch anhand der Frachtschifffahrt, was DDD ist. In seinem Beispiel dreht sich bei Domain alles um den Versand . Wie Fracht bewegt, verwaltet, versendet und verfolgt wird usw. Es gibt eigene, spezifische Regeln, Sprachen und Prozesse. Diese erstellen Domänenmodelle, Objekte, Dienste usw.

Wenn Sie eine Anwendung erstellen, verfügen Sie über eine bestimmte Berechtigung, genau wie in der realen Versandwelt, und nicht jeder kann auf Lager zugreifen. Wie Benutzer autorisiert werden und wie Berechtigungen erteilt werden, kann außerhalb der Domäne liegen , da die Informationen möglicherweise für den Frachtversand nicht relevant sind.

Einfach ausgedrückt: In einer Domain sind Sie geschäftlich tätig . Wenn Ihr Unternehmen Fracht versendet, ist Frachtversand Ihre Domäne. Wenn Ihr Unternehmen Personal authentifiziert und autorisiert, ist dies Ihre Domäne.

Von Domain-Driven Design: Komplexität im Herzen von Software angehen , Eric Evans:

Jedes Softwareprogramm bezieht sich auf eine Aktivität oder ein Interesse seines Benutzers. Der Themenbereich, auf den der Benutzer das Programm anwendet, ist die Domäne der Software.

Die Domäne eines Flugbuchungsprogramms besteht darin, dass echte Personen in echte Flugzeuge einsteigen.

Die Domäne eines Buchhaltungsprogramms ist Geld und Finanzen.

Die Domäne eines Quellcode-Kontrollsystems ist die Softwareentwicklung selbst.

Das Domain-Modell ist dann "eine rigoros organisierte und selektive Abstraktion" des Wissens im Kopf eines Domain-Experten.

Palermo beschrieb die Zwiebelarchitektur anhand dieser Zusammenfassung

Im Zentrum sehen wir das Domänenmodell, das die Kombination aus Zustand und Verhalten darstellt, die die Wahrheit für die Organisation modelliert.

Fowler wiederum bietet an

Ein Objektmodell der Domäne, das sowohl Verhalten als auch Daten enthält.

Wenn Sie sich neuere Definitionen ansehen, werden Sie mit größerer Wahrscheinlichkeit auf Verweise stoßen, bei denen sich das Domänenmodell und das Datenmodell unterscheiden . Ich denke nicht, dass eine Bedeutungsänderung so sehr eine Betonungsänderung ist - die Modellierung des Verhaltens (die Art und Weise, wie sich die Daten als Reaktion auf Informationen von außerhalb des Modells ändern), ist komplexer und variabler als die verschiedenen Arten, Dinge aufzuschreiben .

Da Sie wahrscheinlich bereits eine Vorstellung davon haben, was Domain ist, werden Sie wahrscheinlich als Nächstes versuchen, Sub-Domain, Domain-Modell und, was noch wichtiger ist, begrenzten Kontext zu definieren.

Ich beginne jedoch damit, meine Sichtweise der Domäne zu definieren.

Domain

Domain ist die Realität, in der wir leben: Entitäten, ihr Verhalten, Gesetze, denen sie gehorchen. Es existierte vor uns und wird nach uns existieren, in der einen oder anderen Form. Ihre Existenz hängt nicht von unserem Bewusstsein ab. Marketer kommen mit neuen Funktionen und führen Marktanalysen durch. Key Account Manager kommunizieren mit Kunden, Softwareentwickler automatisieren Geschäftsprozesse. Aus diesem Grund wird die Domain als Problemraum bezeichnet.

Subdomains

DDD impliziert die Zerlegung von Domänen in Unterdomänen, um deren Modellierung und Verständnis zu erleichtern. Die Tatsache, dass Sie ein Geschäft betreiben, lässt darauf schließen, dass es mindestens einen vorherrschenden Geschäftswert gibt. Die, mit der du Geld verdienst. Die, für die wir unser Geschäft gestartet haben. Selbst wenn Sie ein solches Wort wie „Kerndomäne“ nicht kennen, ist es dennoch vorhanden. Gleiches gilt für Subdomains: Möglicherweise benötigen Sie eine Buchhaltung, Personalabteilung und technischen Support - dies ist jedoch zweitrangig.

Domain-Modell

Es ist nicht erforderlich, extrahierte Unterdomänen in ihrer Gesamtheit zu modellieren. In jeder Unterdomäne, an der wir interessiert sind, gibt es einen bestimmten Satz von Regeln. Ein Regelsatz in einer Unterdomäne, der zum Erreichen eines bestimmten Geschäftsergebnisses erforderlich ist, wird als Modell bezeichnet.

Grenzenlose Kontexte

Das Wichtigste ist, dass der begrenzte Kontext eine logische Grenze ist.

Wenn sowohl die Unterdomänen als auch die Kerndomäne definiert sind, ist es Zeit, den Code zu implementieren. Eingeschränkter Kontext definiert konkrete Grenzen der Anwendbarkeit einiger Unterdomänen. Es ist ein Bereich, in dem eine bestimmte Unterdomäne sinnvoll ist, während die anderen dies nicht tun. Es kann ein Vortrag sein, eine Präsentation, ein Code-Projekt mit physischen Grenzen, die durch das Artefakt definiert werden.

Was kommt als nächstes?

Wenn Sie daran interessiert sind, wie das Konzept des begrenzten Kontexts mit dem Konzept der Unterdomäne korreliert, wie die Unterdomänen und begrenzten Kontexte definiert werden, wie die Kommunikation untereinander dargestellt wird und wie Teams unter Berücksichtigung dieser Konzepte organisiert werden, sind Sie wahrscheinlich daran interessiert weiter lesen .