Wie man beschränkte Kontexte darstellt?

Question

Ich meine - physikalisch, in Code. Organisation von Namensgebung, Namespaces, Ordnern, Assemblies, Datenbank/en.

Wie beschränkte Kontexte interagieren sollten?

Zum Beispiel, fühlen Sie sich frei, klassische e-commerce business domain zu verwenden.

Answer 1

Ich würde sagen, ‚es hängt‘

Manchmal könnte es genug, um Ihre BC Einheiten auf die gleiche Datenbank abzubilden und manchmal können Sie verschiedene Datenbanken für Ihre BC haben.

IMO, E-Commerce könnte mehr eine BC als eine vollständige Domäne sein.

Ich habe ein bisschen zu viel Zeit in einem ganzen Verkaufsagenten verbracht, wo sie Lebensmittelprodukte verkauft haben.

So war die Domain „vollständige Verkäufe“ und die begrenzten Kontexten war, Inventur, Einkauf, Verkauf, Fakturierung, Produktkatalog und E-Commerce (vielleicht benutze ich das hier falsch Englisch Wortlaut)

Jede dieser BC wusste über "Produkte", aber sie alle hatten ihre unterschiedliche Sicht auf ein Produkt.

z.B. Beim Kauf könnte eine Produkteinheit mit Lieferanteninformationen, Kaufpreisen usw. angehängt sein.

Während ein Produkt in der E-Commerce-Domain würde von einem Kunden Sicht modelliert werden, wäre es Informationen, die für die Kunden hat, die sie, ihren spezifischen Preis etc.

den E-Commerce-BC betrachtet würde Holen Sie sich Produktinformationen aus mehreren Quellen; Produktkatalog und Verkauf. , wobei die Basisinformationen aus dem Produktkatalog stammen und kundenspezifische Preise aus Verkäufen stammen.

So das Produkt Repository in dem E-Commerce-BC könnte kontext Mapping von der anderen BC tut (über Dienstleistungen von einer Art, höchstwahrscheinlichem Web oder wcf in meinem Fall) unsere E-Commerce-Produkteinheit zu konstruieren)

Persönlich modelliere ich dies als separate Baugruppen, würde ich ein E-Commerce-Modell und ein Verkaufsmodell haben.

Die meisten Informationen in meinem E-Commerce-Modell würden aus externen Quellen stammen und wären nicht lokal persistent. Nur Dinge wie shopping-cart wären lokal persistent, da diese Objekte dem E-Commerce-Modell gehören.

Sobald ein Kunde versucht, den Kauf abzuschließen, würde ich eine Vorbestellung aus dem Einkaufswagen erstellen und diese dann an den Verkauf BC übergeben. Entweder durch einen direkten Dienstanruf oder durch eine Nachrichtenwarteschlange.

Kurz gesagt, ich neige dazu, meine Systeme um ein bestimmtes BC zu bauen und nur mit anderen BCs durch Dienste zu interagieren.

Ich weiß, dass viele Leute ihre BCs in die gleichen Baugruppen setzen und mehrere BC's von der gleichen App etc. verwenden. Aber ich finde es nur seltsam, warum eine App für einen bestimmten Zweck über mehrere Kontexte wissen sollte. Ich möchte es lieber über nur einen Kontext informieren und dann die Daten, die ich benötige, an andere Apps weitergeben.

Answer 2

Ich stimme sicherlich zu, dass alles davon abhängt, aber es gibt einige Richtlinien, die befolgt werden können/sollten.Der Zweck von begrenzten Kontexten ist, na ja, Grenzen. Grenzen, die sich auf einen Teil der Anwendung von einem anderen durch die Einführung eines gut definierten Vertrags (Schnittstelle) trennen.

Ich neige dazu, BCs wie Services in SOA zu behandeln. Für mich bedeutet das idealerweise, dass es sich um physisch getrennte Anwendungen handelt (OS-Prozesse/IIS-Websites). Binaries sind natürlich auch getrennt. Die gesamte Kommunikation zwischen BCs ist idealerweise asynchron. In der realen Welt ist es kaum möglich, aber zumindest erlaube ich keine Cross-BC-Transaktionen, denn sie sind pures Böses.

Hoffnung, das hilft.