it-swarm.com.de

Was ist eine Domain?

Ich sehe diesen Begriff häufig im Kontext der Softwarearchitektur ("Domänenmodell", "domänengesteuertes Design" usw.). Ich habe es gegoogelt, aber ich bekomme Tonnen von verschiedenen Definitionen. Also was ist es wirklich?

107
Sipo

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

Evans geht jedoch noch weiter. Seiner Ansicht nach gibt es auch mit derselben Software Subdomains. Und dies 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 Subdomains.

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 darum geht es ihm bei der Erörterung des strategischen Designs 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 kaufen würde. Normalerweise sieht Evans darin die Domain, die den geringsten Prozentsatz an Code enthält. Sie können sich das als die wichtigsten 20% vorstellen. Dies ist der Teil, den Sie nicht wirklich von der Stange kaufen können, und es kann sich nur um ein einzelnes Modul oder eine einzelne Komponente der gesamten Software handeln.

Die unterstützende Domäne ist immer noch wichtig und kann für die Organisation eindeutig sein, ist jedoch nicht so wichtig wie die Kerndomäne. Ohne sie wird die Software nicht so wertvoll sein 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 gesamte Domäne. Wenn Sie beispielsweise über ein Versandsystem verfügen, das Pakete weiterleitet, oder über ein System für Patientenakten, das Patienten verwaltet, ist die generische Domäne der Teil dieser Systeme, der häufig und gerecht ist müssen einfach da sein, um überhaupt zu funktionieren. Dies macht wahrscheinlich den größten Teil des Systems insgesamt aus, muss aber nicht.

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-Website, in denen er diese Konzepte ausführlicher erklärt.

Während wir in der Software häufig von „der Domäne“ in der Software 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, könnten diese Konzepte in Evans 'Buch beschönigen, aber ich bin der Meinung, dass die Konzepte beim Schreiben und Planen eines Softwareprojekts immer noch nützlich sind.

10
RibaldEddie

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

Ein spezielles Beispiel für eine Domäne könnte so etwas wie "die automatisierte Bearbeitung komplizierter Teile mit einem Hochgeschwindigkeits-Rotationsschneider" sein. Das Software- und Hardwaresystem, das dies erreicht, heißt CNC mill .

Ein weiteres Beispiel für eine Domain ist die Buchhaltung eines Unternehmens.

Weiterführende Literatur
Bounded Context von Martin Fowler

110
Robert Harvey

Dies bedeutet einfach den Problembereich, in dem Sie arbeiten. Wenn Sie beispielsweise eine E-Commerce-Website erstellen, ist Ihre Domain "E-Commerce" und umfasst die Prozesse, die mit den Verkaufspraktiken Ihres Kunden/Unternehmens verbunden sind. Ein Domain-Modell würde also ein Produkt, eine Rechnung oder einen Versanddatensatz darstellen.

40
Becuzz

A Domain is an area of knowledge. It can be though about as an activity in which problems solved by your software exist. ( 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 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 Berechtigung, genau wie in der realen Versandwelt, 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 Versand von Fracht nicht relevant sind.

Einfach ausgedrückt: In einer Domain machen Sie Geschäfte . Wenn Ihr Unternehmen Fracht versendet, ist der Versand von Fracht Ihre Domain. Wenn Ihr Unternehmen Personal authentifiziert und autorisiert, ist dies Ihre Domain.

20
potfur

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 Airline-Buchungsprogramms umfasst echte Personen, die in echte Flugzeuge steigen.

Die Domäne eines Buchhaltungsprogramms ist Geld und Finanzen.

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

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

Bei der Beschreibung der Zwiebelarchitektur bot Palermo diese Zusammenfassung an

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

Fowler wiederum bietet

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

Wenn Sie sich neuere Definitionen ansehen, stoßen Sie mit größerer Wahrscheinlichkeit auf Referenzen, bei denen das Domänenmodell und das Datenmodell unterschiedlich sind . Ich bin nicht der Meinung, dass eine Änderung der Bedeutung vielmehr eine Änderung der Betonung - die Modellierung des Verhaltens (die Art und Weise, wie sich die Daten als Reaktion auf Informationen von außerhalb des Modells ändern) komplexer und variabler ist als die verschiedenen Arten, Dinge aufzuschreiben .

7
VoiceOfUnreason

Da Sie wahrscheinlich bereits eine Vorstellung davon haben, was eine Domain ist, besteht der nächste Schritt vermutlich darin, die Subdomain, das Domain-Modell und vor allem den begrenzten Kontext zu definieren.

Ich beginne jedoch damit, meine Perspektive der Domäne zu setzen.

Domain

Domäne ist die Realität, in der wir leben: ihre 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. Vermarkter entwickeln neue 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 vereinfachen. Die Tatsache, dass Sie ein Unternehmen führen, lässt darauf schließen, dass mindestens ein Unternehmenswert vorherrscht. Der, mit dem 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: Wahrscheinlich benötigen Sie eine Buchhaltung, Personal, technischen Support - aber es ist zweitrangig.

Domänenmodell

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

Begrenzte Kontexte

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

Wenn sowohl Unterdomänen als auch die Kerndomäne definiert sind, ist es Zeit, den Code zu implementieren. Der begrenzte Kontext definiert greifbare Grenzen der Anwendbarkeit einer Unterdomäne. In diesem Bereich ist eine bestimmte Subdomain sinnvoll, während die anderen dies nicht tun. Es kann ein Vortrag, eine Präsentation, ein Codeprojekt mit physischen Grenzen sein, 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 Subdomäne korreliert, wie Sie Subdomänen und begrenzte Kontexte definieren, wie Sie ihre Kommunikation untereinander darstellen und wie Sie Teams unter Berücksichtigung dieser Konzepte organisieren, sind Sie wahrscheinlich daran interessiert weiterführende Literatur .

2
user286277