Wie man einen freigegebenen Kern (DDD) in .Net richtig einführt

Question

Ich habe eine Legacy-App, die ich neu entwerfe, weil es an dieser Stelle ein "Ball of mudd" ist, keine Layering oder SOC. Das Team ist es gewohnt, modular zu arbeiten, dh es gibt ein Team, das an "Training", "Job Opportunities" arbeitet, eines, das an einem Modul arbeitet, das "Duty Planning (Militär)" verwaltet. Wir haben eine Website, die diese Bereiche unseren Kunden als ein Portal von Dienstleistungen, einer Datenbank und einigen externen Apps, die wir bedienen, zugänglich macht.

Ich bin gut dabei, die meisten Schichten neu zu entwerfen, außer wie man die Domäne richtig partitioniert (ich sollte an dieser Stelle erwähnen, dass wir .Net 4.0 verwenden). Mein ursprünglicher Gedanke war, dass dies beschränkte Kontexte waren wegen der Art, wie sie arbeiteten, sie schienen wirklich verschiedene Benutzergruppen zu haben, aber ich glaube jetzt die Realität ist, dass Leute, die diese Seite benutzen, viele Bereiche auf einmal benutzen können. Sicher, einige Gruppen verwenden NUR einen Service, aber viele verwenden mehrere. Das Ziel der Website ist die zentrale Verwaltung von "Mitgliedern". Zwischen den Modulen haben wir Klassen, die einzigartig für das Modul sind, und dann haben wir einige gemeinsame Klassen, zum Beispiel ist das Konzept eines Mitglieds bekannt und wird von allen Modulen verwendet. Mitglied ist eigentlich ein Kernkonzept, die Website bietet Mehrwert, indem Mitgliederinformationen in allen diesen Bereichen gleichzeitig verfolgt werden. Das ist im Grunde genommen ein paar eng miteinander verbundene, aber getrennte Bereiche im System und ein gemeinsamer Bereich. Ich hoffe, das ist klar genug, um die Frage zu beantworten, die ich habe.

Ich denke, ich hätte immer noch einen gemeinsamen Kernel, auch wenn dies keine beschränkten Kontexte sind, für die gemeinsamen Entitäten und gemeinsamen Domänenschnittstellen wie eine generische Repository-Schnittstelle. Wäre es klug, den gesamten gemeinsamen Code (generisches Repository, Kerndomänenmodell, gemeinsamer Kernel usw.) in denselben Namespace oder dieselbe Namespace-Hierarchie zu stellen, und sollte ich diesen Namespace in seiner eigenen Assembly isolieren? Würde ich dann jeden Bereich ("Training", "Opportunities" ...) in ihre eigenen Assemblies ausbrechen oder ist es besser, sie alle in einer Assembly zu haben und sie logisch nach Namespace zu partitionieren. Auf der einen Seite ist es etwas einfacher, die Module physisch partitioniert zu sehen, aber ich bin besorgt über Situationen, in denen zwei Module zusammenarbeiten müssen, um ein Problem zu lösen. Wie würden sie kommunizieren und Dinge azyklisch halten (durch Dienste in der Anwendungsebene, die ich vermute).

so (Zusammenfassung der Optionen):

Domain.Model (dll) - Domain.Model.Core - Kernel (gemeinsam genutzten Einrichtungen und Kerndomäne-Modell) - RepositoryFramework - usw. .. - Domain.Model.Training - Domain.Model.Opportunities ...

oder

Domain.Model.Core

Domain.Model.Training (dll)

Domain.Model.Opportunities (dll) (wie tun Ausbildung und Möglichkeiten zusammenarbeiten?)

Vielen Dank für Ihre Zeit,

Answer 1

Im Falle eines physischen Layouts würde ich alles (das gesamte Domänenmodell) in eine Assembly einfügen. Die Verwendung separater Assemblys bringt keinen Vorteil, während es die Dinge kompliziert und die Kompilierungszeit erhöht. Wenn andererseits das Risiko besteht, dass einige Entwickler ungeeignete Klassen verwenden (diejenigen, die zu einem anderen Modul/Kontext gehören), kann es sinnvoll sein, die Logik in eine gemeinsame Assembly (Kerndomäne, gemeinsam genutzter Kernel) zu unterteilen Baugruppen für jedes Modul/Kontext.

Bei logischem Layout (Namespaces) würde ich jedem Teil einen eigenen Namespace geben (zB DomainModel.Core, DomainModel.Training). Manchmal ist es sinnvoll, einen Schritt weiter zu gehen und jedes Aggregat in seinen eigenen Namensraum zu stellen. Es verhindert, dass die Aggregatgrenzen versehentlich überschritten werden, da es eine separate Verwendungsrichtlinie benötigt.

Hoffnung, die Sinn macht.