Kann es innerhalb einer Anwendung mehrere beschränkte Kontexte geben?
Sie können wählen, mehrere begrenzt Kontexte innerhalb einer einzigen Anwendung zu organisieren, wie Namespaces/Ordner die Wahl etwas, sie zu trennen:
/domain /Claims /Policy.cs /Inspections /Policy.cs /Underwriting /Policy.cs
(diese „Politik“ Beispiel ist von DDD Destilliertes)
der Vorteil eines solchen Ansatzes ist die Einfachheit, obwohl es eine Reihe von Nachteilen hat:
- Mit höherer Wahrscheinlichkeit zu Blutungen und Kontaminationen zwischen Kontexten führen - es ist zu einfach, Objekte aus einem anderen Kontext zu referenzieren, wenn sie sich alle im gleichen Projekt befinden.
- Schwieriger zu verwalten wenn mehrere Teams arbeiten an der Anwendung
- Weniger Wahl, wenn es um Einsatz kommt (möglicherweise kein Problem sein)
wenn ja, was ist, wenn ein Kontext bestimmt, soll zusammen mit einem anderen Kontext oder wenn sie eingesetzt werden, sollte als eigenständige Einheit eingesetzt werden?
Sie müssen die Vor- und Nachteile berücksichtigen, sie in einer einzigen Anwendung zu haben, anstatt sie aufzuteilen. Einige davon habe ich bereits oben erwähnt, aber es gibt noch andere Dinge, die zu beachten sind.
Haben die verschiedenen Kontexte unterschiedliche nicht-funktionale Anforderungen? d.h. Skalierung, Leistungsbedarf usw.? Wenn dies der Fall ist, sollten Sie sie separat bereitstellen können, sodass sie nicht Teil derselben Anwendung sein sollten.
Sind Sie in irgendeiner Weise durch die Technologien, die Sie auswählen können, oder die Server, auf denen Sie bereitstellen können, eingeschränkt? Möglicherweise gibt es Einschränkungen, die den Wechsel zu einer Microservices-Architektur erschweren.
Es gibt auch ein organisatorisches Element zu dieser Frage und es hängt von der Art der Organisation ab, in der Sie sich befinden. Haben Sie mehrere Teams, die an Ihrem System arbeiten? Wenn Sie in einer Organisation arbeiten, deren Hauptgeschäft IT-basiert ist, werden Sie oft feststellen, dass das Unternehmen bereits einige Entscheidungen für Sie getroffen hat, indem sie Teams und Strukturen organisiert haben (siehe Conways Gesetz), die auf Kontexte ausgerichtet sind. Ob diese Teilung das ist, was Sie eigentlich wollen/korrigieren, ist eine andere Frage. In anderen Organisationen sind Sie möglicherweise "die IT-Abteilung" oder etwas allgemeineres. In diesem Fall haben Sie wahrscheinlich mehr Kontrolle darüber, wie Sie Dinge modellieren und organisieren.
Wenn ich mehr begrenzt Kontexte innerhalb einer Anwendung (Einsatz-Einheit) und ein Client (zum Beispiel eines UI) erfordert Informationen von mehreren Kontexten gleichzeitig, soll ich einen neuen Anwendungsdienst schaffen, um zu unterstützen, Dieses Szenario dann?
als @ plalx Erwähnungen in den Kommentaren, können Sie diese Aggregation entweder Client-Seite oder Server-Seite tun. Stellen Sie sich eine Seite mit 3 Widgets vor, bei der jedes Widget einen AJAX-Aufruf an einen anderen Kontext (wenn Sie sie teilen) erstellt und die Benutzeroberfläche auf diese Weise zusammensetzt. Alternativ könnten Sie die Serverseite aggregieren, d. H. Eine Art von Lesemodell für die betreffende UI haben.
Sie können mehrere Integrationsmethoden verwenden. Eine UI kann zu einem bestimmten Kontext gehören oder nicht. Sie können über Composite-UIs verfügen, bei denen die UI aus mehreren Komponenten zusammengesetzt ist, die zu verschiedenen BCs gehören und in diesen verwaltet werden. Möglicherweise verfügen Sie auch über eine Benutzeroberfläche, die mit mehreren BCs kommuniziert, oder um die Aggregation im Back-End durchzuführen. Alle Integrationsmethoden sind praktikabel und haben Vor- und Nachteile. Vielleicht möchten Sie Patterns, Principles and Practices von Domain-Driven Design lesen, die ein Kapitel dazu enthalten. – plalx