Extensibility mit DDD: Modul Vs begrenzten Kontext in DDD mit MEF

Question

Eric in seinem Buch berührt das Thema Module sehr wenig. Er spricht auch nicht über die Beziehung der Struktur von Modulen zu beschränkten Kontexten mit Beispielen. Haben Bounded Contexts Module oder Module die Bounded Contexts? Wenn eine Anwendung über DDD verfügt, wie einfach kann es erweiterbar sein?

Die Struktur der Anwendung ist sehr wichtig, wenn wir erweiterbare Anwendungen entwerfen. Das Microsoft MEF-Framework kann Module/Komponenten aus einer DLL automatisch erkennen.

Nehmen wir ein Beispiel. In einer E-Commerce-Anwendung können wir einen beschränkten Kontext für Payment Processing haben. Die Zahlungsabwicklung kann abstrakt sein, so dass ich später die App um weitere Zahlungsprozessoren wie Paypal oder Payflow erweitern kann. Momentan habe ich nur Paypal und einige Monate später möchte ich Payflow integrieren. Um Payflow zu integrieren, kann ich eine Assembly (eine DLL) haben, die die Schnittstelle Payment Processing implementiert. Ich kann diese DLL in der Anwendung löschen, und das MEF wird es automatisch erkennen.

Die Herausforderung hier ist, die für die PayFlow-Zahlungsabwicklung erstellte DLL ist ein Modul, kein Bounded Context (BC). Wenn ich es als BC erstellt habe, haben wir zwei BCs für Payment Processing. (Das BC wurde für Paypal und das BC für den Payflow erstellt). Wenn wir die Anwendung mit Modulen in einem beschränkten Kontext und dem beschränkten Kontext als eine Assembly (DLL) strukturieren, können sich die Module im BC als Ordner und nicht als Assemblys befinden (Sie können sich diese als in Visual Studio erstellte C# -Bibliothek vorstellen).

Wie können wir dieses Erweiterungsproblem mit DDD umgehen? Ist Zahlung Verarbeitung, ein BC und verschiedene Ordner darunter als Module, eine für Paypal etc ... Oder brauchen wir Sub-BC in einem anderen BC?

Answer 1

Eric in seinem Buch berührt das Thema Module sehr wenig. Er auch spricht nicht über die Beziehung der Struktur von Modulen zu begrenzten Kontexten mit Beispielen.

Ja, ich stimme, dass Modul und BC Struktur keine ausreichende Deckung im Buch. Ich empfehle Implementing Domain-Driven Design by Vaughn Vernon für mehr dazu.

Do Begrenzte Kontexte enthalten Module oder Module enthalten die Grenzen Kontexte?

BCs enthalten Module. Ein Modul ist wie ein leichtes BC und gehört auch in die allgegenwärtige Sprache.

Wenn eine Anwendung DDD hat, wie einfach kann es erweiterbar sein?

Das hängt, wie Sie Architekt davon abhängt. Nichts an DDD selbst würde die Erweiterbarkeit verhindern.

Ist Payment Processing, ein BC und verschiedene Ordner darunter als Module, eines für Paypal etc ... Oder haben wir in einem anderen BC Unter BC benötigen?

Ich würde jede Zahlungsprozessor-Integration als ein Modul innerhalb einer einzigen Payment Processing BC modellieren. Darüber hinaus ist jede Integration eine ACL zwischen Ihrem Zahlungsverarbeitungsmodell und einem Drittanbieter wie PayPal.

Oder brauchen wir Sub-BC in einem anderen BC?

Nein, aber dies berührt eine interessante Vorstellung von einem Sub-BC. Ich glaube nicht, dass ein Sub-BC eine gute Idee ist, weil ich glaube, dass hierarchische Organisationen gefährlich sein können, was zu starren Designs führt (siehe zum Beispiel OOP mit expliziten Typhierarchien - kann problematisch sein). Wählen Sie stattdessen ein flacheres Modell mit potenziell mehr BCs. Auch in Ihrem Fall kann die gewünschte Strukturierung mit Modulen erreicht werden.