In Julie Lerman das Beispiel mit Entity Framework (EF) sie Modelle ein Contact unter zwei verschiedenen begrenzten Kontexten - Sales Order (nur gelesen werden) und Contact Management (als persistierbar)). Wie Eben vorschlägt, diese Entitäten letztendlich konsistent zu halten, kann dies unter Verwendung eines Nachrichtensystems erreicht werden - in Julies Beispiel verwendet sie das Domänenereignis ContactUpdatedEvent, das von einem Dienst abonniert werden kann, um ein Modell innerhalb eines anderen beschränkten Kontexts zum erneuten Lesen aus einer Datenquelle zu erzwingen (ob dies eine Datenbank ist oder das Ereignis selbst die Daten in einem DTO zum Beispiel enthält), wenn dieses Ereignis veröffentlicht wird - dies wird dazu beitragen, die Konsistenz der Daten zu gewährleisten.
Da Ihr Controller/View-Modell/Presenter/Services direkt mit einer abstrahierten Schnittstelle für persistente Änderungen interagieren soll, dh das Repository-Muster und nicht direkt den EF db-Kontext, kommt im obigen Beispiel ein Contact aus einem Repository unter einem Stammaggregat und die anderen Contact unter ein anderes Stammaggregat kommen - daher unterstützen die beiden Contact Entitätsimplementierungen die Persistenz der Stammaggregate auf unterschiedliche Weise, wobei der Sales Order Kontext die Persistenz der Contact Einheit verhindert.
Da Sie die Contact unter zwei verschiedenen begrenzten Kontexten darstellen, sollten sie nicht das gleiche Verhalten haben, also sollten Sie sich keine Gedanken über Codeverdopplungen machen, abgesehen von der Benennung von Eigenschaften zum Abrufen/Setzen von Daten, aber ich bin sicher, dass du damit leben kannst. Zum Beispiel könnte eine Aktion "Einen Kontakt zur Überprüfung ihrer Bestellung bitten" mit dem Verhalten in der Contact Klasse unter dem Contact Management Kontext dargestellt werden, aber KANN keine Relevanz in der Contact Klasse auf dem Sales Order Kontext haben.
Die EF zwingt Sie nicht, Zuordnungen zwischen Entitäten in beiden Richtungen zu haben. Das Fluent-API-Mapping bietet eine große Flexibilität und ermöglicht Ihnen, diese Zuordnungen auf eine Weise zu verwenden.
Wenn die Idee Ihres Projekts ist DDD folgen, dann würde ich vorschlagen, Sie vergessen, über die Datenbank und EF vollständig zu beginnen und In-Memory-Repositories zum Lesen und Persistent Ihre Root-Aggregate verwenden. Sie können sich dann darauf konzentrieren, Ihre Domain-Entitäten zu einem späteren Zeitpunkt mit der EF Fluent-API zu Ihrer Datenbank zuzuordnen. Auf diese Weise werden Sie nicht gezwungen, Ihr Domain-Modell zu ändern, damit es in Ihre Datenbank passt.
Danke, Entity Framework erwartet Navigation Eigenschaft auf beiden Seiten der Assoziation vorhanden sein, sonst hätte ich gut mit Fremdschlüsseln verwaltet werden, anstatt meine EF-Kontext in Vielfachen zu brechen. Irgendwelche Gedanken zur Abhilfe? – Abhijeet
Leider bin ich kein Fan von irgendeinem ORM-Tool. Es sollte jedoch auch kein Problem sein, da Sie eine sehr harte Grenze um Ihr Aggregat haben sollten. Sie laden also entweder nur die ID für das fremde/vorgelagerte AR oder ein Wertobjekt. Ich weiß nicht, wie EF ein VO wieder aufbauen würde. Ich denke, NHibernate hat eine * Komponente * oder etwas in diesem Sinne. EF sollte etwas ähnliches haben. –