Wir entwickeln ein System, das aus mehreren begrenzten Kontexten besteht. Es gibt Benutzeroberflächen, auf denen die angezeigten Informationen aus mehreren beschränkten Kontexten gerendert werden müssen.
Ein klassisches Beispiel für eine solche Schnittstelle ist die Bestellseite von Amazon.com. Wo wir über das Produkt (Produkt BC), Inventar verfügbar (Inventar BC), Preise und so weiter sehen.
Meine Frage: In welchen Szenarien, in welchem Kontext würde die Benutzeroberfläche leben? Ich bekomme, wie wir Daten aus mehreren BCs ziehen können, um die Seite zu bilden, aber gibt es irgendwelche Richtlinien, wo die Seite selbst liegen sollte?
Ähnliche Fragen hier und hier , sie beschäftigen sich damit, wie man Informationen aus den mehreren BC's bekommt, aber sie adressieren nicht in welcher BC die Benutzeroberfläche ist selbst wird leben?
Irgendwelche Richtlinien zu dieser Frage Mit einem Beispiel wäre großartig ...
Ich bin kein Experte, aber ich glaube, dass die Benutzeroberfläche nicht in einem BC lebt. Die Benutzeroberfläche ist ein Ausdruck von einem oder mehreren BCs. Das BC ist eine Grenze für Entscheidungen, die miteinander verknüpft sind. Wie Sie das dem Benutzer zeigen, ist nicht seine Sache.
So haben Sie zum Beispiel eine Webseite wie amazon.com mit mehreren BCs, wie Sie sagen, die UI führt Sie einfach mit und hilft Ihnen dabei, Entscheidungen zu treffen, in welcher BC Sie auch involviert sind.
Ein letzter Versuch. Wenn Sie sich ein Diagramm mit einer hexagonalen Architektur oder einer geschichteten Architektur vorstellen, hätten Sie ganz außen (oben) ein UI. Es würde mit einer Anti-Korruptionsschicht (oder einem Anwendungsdienst) kommunizieren. Dieser A-C würde dann an den richtigen BC delegieren, um den Befehl auszuführen, den Sie erfüllen wollten.
Die Benutzeroberfläche hat ihre eigenen Bedenken und Kollaborationsmuster; es ist ein BC für sich.
Tags und Links user-interface domain-driven-design