it-swarm.com.de

DDD - Persistenzmodell und Domänenmodell

Ich versuche, Domain-driven Design (DDD) zu lernen, und ich glaube, ich habe die Grundidee verstanden. Aber etwas verwirrt mich.

Unterscheiden sich in DDD Persistenzmodell und Domänenmodell? Ich meine, wir gestalten unsere Domain und Klassen nur mit Domain-Bedenken. das ist okay. Aber sollten wir beim Erstellen unserer Repositories oder eines anderen Datenpersistenzsystems eine andere Repräsentation unseres Modells erstellen, die in der Persistenzschicht verwendet werden soll?

Ich dachte, unser Domänenmodell wird auch in Persistenz verwendet, was bedeutet, dass unsere Repositorys unsere Domänenobjekte aus Abfragen zurückgeben. Aber heute habe ich diesen Beitrag gelesen und bin etwas verwirrt:

Hör einfach auf! Das Domänenmodell ist nicht das Persistenzmodell

Wenn dies wahr ist, was wäre der Vorteil, getrennte Persistenzobjekte von Domänenobjekten zu haben?

46
ayk

Stellen Sie sich das so vor: Das Domänenmodell sollte auf nichts angewiesen sein und keinen Infrastrukturcode enthalten. Das Domänenmodell sollte nicht serialisierbar sein oder von einigen ORM-Objekten erben oder sogar gemeinsam nutzen. Dies sind alles Infrastrukturprobleme und sollten getrennt vom Domänenmodell definiert werden.

Dies ist jedoch der Fall, wenn Sie nach reinen DDDs suchen und die Skalierbarkeit und Leistung Ihres Projekts über die Geschwindigkeit der anfänglichen Entwicklung hinausgehen. Durch das Mischen von Infrastrukturbelangen mit Ihrem "Domänenmodell" können Sie häufig große Geschwindigkeitssteigerungen auf Kosten der Skalierbarkeit erzielen. Der Punkt ist, Sie müssen sich fragen: "Sind die Vorteile von reinem DDD die Kosten in der Entwicklungsgeschwindigkeit wert?". Wenn Ihre Antwort ja ist, dann ist hier die Antwort auf Ihre Frage.

Beginnen wir mit einem Beispiel, bei dem Ihre Anwendung mit einem Domänenmodell beginnt und die Tabellen in der Datenbank genau zu Ihrem Domänenmodell passen. Jetzt wächst Ihre Anwendung sprunghaft an und es treten Leistungsprobleme beim Abfragen der Datenbank auf. Sie haben einige durchdachte Indizes angewendet, aber Ihre Tabellen wachsen so schnell, dass es so aussieht, als müssten Sie Ihre Datenbank deaktivieren, um mithalten zu können. Mit Hilfe eines dba stellen Sie sich also ein neues Datenbankdesign vor, das Ihren Leistungsanforderungen gerecht wird. Jetzt unterscheiden sich die Tabellen jedoch erheblich von dem, was sie zuvor waren, und jetzt verteilen sich die Blöcke Ihrer Domänenentitäten auf mehrere Tabellen als es eine Tabelle für jede Entität ist. 

Dies ist nur ein Beispiel, aber es zeigt, warum Ihr Domänenmodell von Ihrem Persistenzmodell getrennt sein sollte. In diesem Beispiel möchten Sie die Klassen Ihres Domänenmodells nicht aufteilen, um die Änderungen zu berücksichtigen, die Sie am Entwurf des Persistenzmodells vorgenommen haben, und die Bedeutung Ihres Domänenmodells grundlegend zu ändern. Stattdessen möchten Sie die Zuordnung zwischen Ihrem neuen Persistenzmodell und dem Domänenmodell ändern.

Es gibt mehrere Vorteile, diese Designs voneinander zu trennen, z. B. Skalierbarkeit, Leistung und Reaktionszeit bei Änderungen der Notfalldatenbank. Sie sollten sie jedoch gegen die Kosten und die Geschwindigkeit der ursprünglichen Entwicklung abwägen. Im Allgemeinen sind die Projekte, die am meisten von dieser Trennung profitieren, große Unternehmensanwendungen.

UPDATE FÜR KOMMENTATOREN

In der Welt der Softwareentwicklung gibt es eine n-te Anzahl möglicher Lösungen. Aus diesem Grund besteht eine indirekte inverse Beziehung zwischen Flexibilität und anfänglicher Entwicklungsgeschwindigkeit. Als einfaches Beispiel könnte ich die Logik in eine Klasse hartcodieren oder eine Klasse schreiben, die die Übergabe von dynamischen Logikregeln ermöglicht. Die frühere Option hätte eine höhere Entwicklungsgeschwindigkeit, jedoch einen geringeren Flexibilitätsgrad. Die letztere Option hätte ein höheres Maß an Flexibilität, jedoch auf Kosten einer geringeren Entwicklungsgeschwindigkeit. Dies gilt für jede Programmiersprache, da es immer eine N-te Anzahl möglicher Lösungen gibt.

Es stehen viele Tools zur Verfügung, mit denen Sie Ihre anfängliche Entwicklungsgeschwindigkeit und Flexibilität steigern können. Ein ORM-Tool kann beispielsweise die Entwicklungsgeschwindigkeit für den Datenbankzugriffscode erhöhen und bietet Ihnen außerdem die Flexibilität, die vom ORM unterstützten Datenbankimplementierungen auszuwählen. Aus Ihrer Sicht ist dies ein Nettogewinn sowohl an Zeit als auch an Flexibilität abzüglich der Kosten des Tools (von denen einige kostenlos sind), die sich aufgrund der Entwicklungskosten im Verhältnis zum Wert des Tools für Sie möglicherweise lohnen oder nicht Geschäftsanforderungen. 

Für diese Konversation in Codierungsstilen, die im Wesentlichen Domain Driven Design ist, müssen Sie jedoch die Zeit berücksichtigen, die zum Schreiben des von Ihnen verwendeten Tools benötigt wurde. Wenn Sie dieses ORM-Tool schreiben oder sogar Ihre Datenbankzugriffslogik so schreiben, dass alle von diesem Tool bereitgestellten Implementierungen unterstützt werden, würde dies viel länger dauern, als wenn Sie die von Ihnen geplante Implementierung nur hart codieren würden bei der Verwendung.

Zusammenfassend können Sie mit Hilfe von Tools Ihre eigene Zeit für die Produktion und den Preis für Flexibilität ausgleichen, indem Sie die Kosten dieser Zeit an alle Personen verteilen, die das Tool erwerben. Jeder Code, der den Code enthält, der ein Tool verwendet, bleibt jedoch von der Geschwindigkeits-/Flexibilitätsbeziehung beeinflusst. Auf diese Weise ermöglicht Domain Driven Design eine größere Flexibilität als wenn Sie Ihre Geschäftslogik, den Datenbankzugriff, den Dienstzugriff und den Code der Benutzeroberfläche alle miteinander verwickeln würden, jedoch auf Kosten der Produktionszeit. Domain Driven Design eignet sich für Anwendungen auf Unternehmensebene besser als kleine Anwendungen, da Anwendungen auf Unternehmensebene für die anfängliche Entwicklungszeit in Bezug auf den Unternehmenswert tendenziell höhere Kosten verursachen und weil sie komplexer sind, sie auch Änderungen unterliegen, die eine höhere Flexibilität erfordern Reduzierte Kosten in der Zeit.

54
Aaron Hawkins

Unterscheiden sich bei DDD Persistenzmodell und Domänenmodell?

Ja, aber das impliziert nicht notwendigerweise einen anderen Satz von Klassen, um das Persistenzmodell explizit darzustellen. 

Wenn Sie eine relationale Datenbank für die Persistenz verwenden, kann ein ORM wie NHibernate dafür sorgen, dass das Persistenzmodell durch Zuordnungen zu Domänenklassen dargestellt wird. In diesem Fall gibt es keine expliziten Klassenmodelle für die Persistenz. Der Erfolg dieses Ansatzes hängt von den Mapping-Fähigkeiten des ORM ab. NHibernate kann beispielsweise eine Zwischenzuordnungsklasse durch Komponentenzuordnungen unterstützen. Dies ermöglicht bei Bedarf die Verwendung einer expliziten Persistenzmodellklasse.

Wenn Sie eine Dokumentendatenbank für die Persistenz verwenden, ist ein Persistenzmodell in der Regel noch weniger erforderlich, da das Domänenmodell nur serialisiert werden muss, um persistent zu sein. 

Verwenden Sie daher eine explizite Persistenzmodellklasse, wenn eine komplexe Zuordnung vorhanden ist, die mit ORM-Zuordnungen zum Domänenmodell nicht erreicht werden kann. Der Unterschied zwischen dem Domänenmodell und dem Persistenzmodell bleibt unabhängig von der Implementierung.

13
eulerfx

Unterscheiden sich bei DDD Persistenzmodell und Domänenmodell?

In DDD haben Sie das Domain-Modell und das Repository. Das ist es. Wenn Sie innerhalb des Repositorys Ihr Domänenmodell direkt beibehalten oder in ein Persistenzmodell konvertieren, bevor Sie es festlegen, liegt es bei Ihnen! Es ist eine Frage des Designs, Ihres Designs. 

Wie andere Käufer darauf hingewiesen haben, hat jede Option ihre Vor- und Nachteile. Schauen Sie sich diese answer an, wo ich einige davon ausführlich erläutere.

9

Ihr Domänenmodell unterscheidet sich von Ihrem Persistenzmodell, und das ist in jedem Fall wahr. 

Lassen Sie mich erklären. 

Nehmen wir an, Sie verwenden eine RDB als Ihren Persistenzspeicher. Sie verwenden höchstwahrscheinlich einen ORM. Wenn Sie einen ORM auswählen, ist der Einfluss der anderen von großer Bedeutung, wenn Sie Persistenzmodelle benötigen oder nicht. 

Woher ? 

Vergleichen wir zwei ORMs, die meist in der .NET-Welt verwendet werden.

1st Entity Framework

Es erfordert den folgenden Code, um die Beziehung zu verstehen. 

public class Aggregate
{
    public int Id { get; }

    /// relation
    protected internal virtual IList<Entity> Model { get; private set; }
} 


public class Entity
{
    public int Id { get; }

    /// relation
    public int AggId{ get; private set;}
    public Aggregate Aggregate { get; private set; }
} 

Schauen wir uns jetzt NHibernate an und so modellieren wir unsere Domänenmodelle.

public class Aggregate
{
    public virtual int Id { get; }

    protected internal virtual IList<Entity> Model { get; private set; }
} 

public class Entity
{
    public virtual int Id { get; }
} 

Beachten Sie also den Unterschied in der Art und Weise, wie wir mit dem einen und dem anderen modellieren.

Sprechen wir über das Problem mit EF. Aus meiner Sicht gibt es hier zwei sehr wichtige Domainverletzungen.

1. Wie Sie sehen, erfordert EF Querverweise, um das DB-Schema modellieren zu können. Wenn Sie zu einem bestimmten Zeitpunkt eine Viele-zu-Viele-Beziehung haben, müssen Sie nicht nur die Referenzen in den beiden Domänenmodellen hinzufügen, sondern Sie müssen eine dritte Klasse (eine beitretende Klasse) hinzufügen, die keine hat Ist es ein Aggregat, eine Entität oder ein ValueObject? In Wirklichkeit hat es für Ihr Unternehmen überhaupt keinen Wert. Warum sollten Sie dann gezwungen sein, es zu modellieren? Ihre Domain sollte nur die geschäftlichen Anforderungen berücksichtigen und nicht, wie Daten im Speicher dargestellt werden sollen.

2. siehe dazu http://www.informit.com/articles/article.aspx?p=2020371&seqNum=4

Was kannst du dagegen tun? Wenn Sie EF verwenden, haben Sie, wenn Sie es richtig machen, höchstwahrscheinlich Domänenmodelle (die in diesem einfachen Fall wie NHibernate-Modelle aussehen) und Persistenzmodelle, die Spiegel des DB-Schemas sein werden. Die Domänenmodelle befinden sich in Ihrer Domäne und Ihr Persistenzmodell in Ihrer Infrastruktur. 

Nun zurück zu NHibernate. Sie können davon ausgehen, dass Ihr Domänenmodell mit Ihrem Datenmodell identisch ist. Natürlich verwenden Sie einige Konfigurationen in der Infrastruktur, um die korrekten Beziehungen mit dem Persistenzspeicher zu modellieren. NHibernate zwingt Sie jedoch nicht, in Ihrer Domäne etwas hinzuzufügen du brauchst nicht 

Ich fördere keinen ORM über den anderen, es ist für jeden die Wahl, einen von ihnen zu verwenden, eine Wahl, die von den geschäftlichen Bedürfnissen bestimmt werden sollte. 

Wie wäre es nun mit NoSQL (ohne Schema)? Ihr Domänenmodell ist das gleiche wie Ihr Persistenzmodell. Außerdem benötigen Sie keine Konfiguration zum Modellieren einer Beziehung 

0
MCR