Ich hatte eine Infrastruktur für unser brandneues Intranet-Projekt geschaffen und versucht, fast allen Best Practices zu folgen. Ich möchte auch erwähnen, dass dies das erste Mal ist, dass ich eine Architektur von Null an erstellt habe.
Momentan ist die erste Version meiner Infrastruktur fertig und funktioniert gut. Aber ich möchte beschränkte Kontextstruktur in der nächsten Version implementieren.
Ich habe versucht, die derzeitige Situation zu erklären.
DbCore: verantwortlich für Datenvorgänge. Entity Framework 5 Code Zuerst verwendet. Es gibt nur eine DbContext-Klasse und alle darin definierten DbSets. Auch GenericRepository-Muster und Unit of Work-Muster wurden anhand der folgenden Schnittstellen implementiert.
IGenericRepository
%Vor%IUnitOfWork
%Vor%Modelle: Verantwortliche Speichereinheitsmodelle für DbCore und Entity Framework Domäne: Die Geschäftslogikebene speichert auch DTOs für Entitätsobjekte, die im Models-Projekt gespeichert wurden. Derzeit ist die Geschäftslogik in der Serviceklasse gespeichert, die die folgende Schnittstelle implementiert hat IService
%Vor%Diese Serviceklasse ruft UnitOfWork über den Parameter ctor ab und verwendet sie für Operationen. Auch Automapper implementiert, um Entitätsobjekte in DTOs umzuwandeln oder umgekehrt. Ab jetzt interessieren sich alle oberen Schichten nicht mehr für Entitätsmodelle, sondern nur für DTOs. Daher beziehen sich fast alle Projekte (einschließlich API und Web) auf dieses Projekt.
Allgemein: Verantwortlich für das Speichern häufig verwendeter Bibliotheken wie die Protokollierung.
WebCore: Verantwortlich für das Speichern häufig verwendeter Bibliotheken für webbasierte Projekte wie API oder MVC. Enthält auch Erweiterungen, Handler und Filter für MVC-basierte Projekte.
API: ASP.Net MVC-Web-API-Projekt stellt die Serviceebene dar. Verbraucht Domänenebene und dient Clients. Controller ruft die IService-Schnittstelle als ctor-Parameter ab und verwendet sie, um auf die Datenebene durch die Domänenebene zuzugreifen.
Web: ASP.Net MVC 4-basiertes Webprojekt, verantwortlich für die Interaktion mit dem Benutzer. Verbraucht API-Methoden für den Zugriff auf Daten. Alle Controller erhalten eine Schnittstelle namens IConsumeRepository, die die API über HttpClient verbindet.
%Vor%Autofac ist verantwortlich für IoC und DI für alle Projekte.
Im Moment ist das meine aktuelle Infrastruktur, ich denke, ich habe alles erklärt, was zu bewerten ist.
Jetzt versuche ich, die folgenden Dinge herauszufinden,
Frage 1: Gibt es etwas, das NICHT so angewendet werden darf wie ich?
Frage 2: Was ist der beste Ansatz, um gebundene Kontexte zu implementieren? Ich habe kürzlich Julie Lerman's Videos angeschaut und viele Beispielprojekte besprochen. Was ich gesehen habe, war, dass ich BC von DbContext abgeleitet habe. Aber ich konnte mir nicht sicher sein. Weil ich gedacht hatte, BCs sollten in der Domäne (Geschäftslogik) Schicht nicht in DbCore (Datenzugriff) Schicht sein.
Frage 3: Wie bereits erwähnt, verwenden meine API- und Web-Projekte DTOs, so dass beide Referenzen Domain-Layer haben müssen. Aber ich mochte es nicht, weil ich Business-Schicht von der Benutzeroberfläche mit einer API getrennt und sie wieder für Entitäten gekoppelt habe. Aber ich konnte keinen besseren finden.
Das wurde eine lange Frage, aber ich werde mich sehr freuen, wenn Sie Ihre Ideen mit mir teilen, um bessere Architektur zu schaffen.
Frage 1 : Wenn Sie von einer komplexen Geschäftsdomäne und einer bedeutenden Geschäftslogik ausgehen, kann es sich lohnen, die Domänenschicht von Infrastrukturproblemen zu isolieren. Dies ist jedoch oft nicht der Fall. Wenn Sie Daten nur aus der Datenbank in die Benutzeroberfläche und wieder zurück verschieben, ist dies überdimensioniert und Sie sollten etwas mit weniger beweglichen Teilen suchen.
Frage 2: Wie viele verschiedene Domänenmodelle (mit unterschiedlichen ubiquitären Sprachen) haben Sie? Ein? Zwei? Drei? Isolieren Sie sie für jedes Modell so weit wie möglich von anderen Modellen und Infrastrukturproblemen.
Eric Evans definiert einen begrenzten Kontext als primär linguistische Grenze (Zitat aus seinem Buch):
Ein BEGRENZTER KONTEXT grenzt die Anwendbarkeit eines bestimmten Modells ein Diese Teammitglieder haben ein klares und gemeinsames Verständnis von dem, was ist konsistent sein und wie es sich auf andere CONTEXTS bezieht. Innerhalb dessen CONTEXT, arbeiten, um das Modell logisch einheitlich zu halten, aber keine Sorge über Anwendbarkeit außerhalb dieser Grenzen. In anderen CONTEXTS, andere Modelle gelten, mit Unterschieden in der Terminologie, in Konzepten und Regeln, und in Dialekten der UBIQUITOUS LANGUAGE.
DBContext weist Sie möglicherweise in die richtige Richtung, aber denken Sie daran, es ist ein Infrastruktur Artefakt, nicht ein Domänenkonzept. Es "stellt eine Kombination aus dem Unit-Of-Work- und Repository-Muster dar und ermöglicht es Ihnen, eine Datenbank abzufragen und Änderungen zusammenzufassen, die dann als Einheit in den Store zurückgeschrieben werden." _ (Von MSDN Docs ).
Bei DDD geht es um Domänenmodellierung: Verwenden von Modellen zur Lösung schwieriger Geschäftsprobleme in komplexen Geschäftsdomänen. Das Ableiten von Modellgrenzen aus technischen Überlegungen kann sich wie der Schwanz wedeln lassen. Definieren Sie konzeptionell die Grenze Ihres Modells und richten Sie Ihre technische Infrastruktur entsprechend aus.
Frage 3: DTOs können eine gute Möglichkeit sein, eine Kontextgrenze zu erzwingen, beispielsweise für eine API. Die API kann dann als Anti-Korruptionsschicht für andere Modelle fungieren. Der Grund, warum Benutzer sie normalerweise für Benutzeroberflächen verwenden, besteht darin, zu vermeiden, dass Benutzeroberflächenkonzepte in das Domänenmodell kopiert werden müssen.
Suchen Sie keine perfekte Architektur. Und erkennen, dass "Best Practices" wirklich nur Richtlinien sind, die auf bestimmten Situationen basieren. Befolgen Sie die Richtlinien, die andere erfahrenere Personen aufgestellt haben, mit dem Verständnis, dass Ihre Situation wahrscheinlich subtil anders ist. Verwenden Sie, was Sie haben mit der Erwartung, Ihre Design-Entscheidungen zu refaktorisieren, wenn Sie Reibung finden. Wenn Sie z. B. später feststellen, dass die DTOs auf der Benutzeroberfläche übertrieben sind, entfernen Sie sie. Vereinfachen Sie, wo immer Sie können.