Wie kann man begrenzte Kontexte darstellen?

Question

Ich meine - physisch im Code. Organisation von Benennung, Namespaces, Ordnern, Baugruppen, Datenbank/s.

Wie begrenzte Kontexte sollten interagieren?

Fühlen Sie sich zum Beispiel frei, klassisch zu verwenden E-Commerce Business Domain.

Answer 1

Ich würde sagen: "Es kommt darauf an. '

Manchmal reicht es aus, Ihre BC -Entitäten derselben Datenbank zuzuordnen, und manchmal haben Sie möglicherweise unterschiedliche Datenbanken für Ihre BCs.

IMO, E-Commerce ist möglicherweise eher ein BC als eine vollständige Domäne.

Ich habe etwas zu viel Zeit bei einem ganzen Vertriebsagenten verbracht, wo sie Lebensmittel verkauft haben.

Die Domain war also "ganzer Verkauf" und die begrenzten Kontexte, Inventar, Kauf, Verkauf, Rechnungsstellung, Produktkatalog und E-Commerce (vielleicht verwende ich hier den falschen englischen Wortlaut)

Jeder dieser BCs wusste über "Produkte", aber alle hatten ihre unterschiedliche Sicht auf ein Produkt.

zB Kauf kann eine Produkteinheit mit Anbieterinformationen, Kaufpreis usw. haben.

Während ein Produkt in der E-Commerce-Domäne aus Kunden an Sicht modelliert wird, hätte es Informationen, die für den Kunden relevant sind, der es ansieht, ihren spezifischen Preis usw.

Der E-Commerce BC würde seine Produktinformationen aus mehreren Quellen erhalten. Produktkatalog und Verkauf. Wo die Basisinformationen aus dem Produktkatalog stammen und die kundenspezifischen Preise aus dem Verkauf stammen.

Das Produktrepository im E-Commerce BC könnte also das Kontext-Mapping von den anderen BC (über Dienstleistungen irgendeiner Art, höchstwahrscheinlich Web oder WCF) durchführen, um unsere E-Commerce-Produkteinheit zu konstruieren)

Persönlich modelliere ich dies als separate Baugruppen, ich hätte ein E-Commerce-Modell und ein Verkaufsmodell.

Die meisten Informationen in meinem E-Commerce-Modell stammen aus externen Quellen und wären nicht lokal hartnäckig. Nur Dinge wie das Einkaufen wären lokal hartnäckig, da diese Objekte dem E-Commerce-Modell gehören.

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

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

Ich weiß, dass viele Leute ihre BCs in dieselben Baugruppen einbringen und mehrere BCs aus derselben App usw. verwenden. Ich finde es jedoch nur seltsam, warum eine App für einen bestimmten Zweck über mehrere Kontexte Bescheid wissen sollte. Ich würde es lieber über einen Kontext informieren und dann alle Daten übergeben, die ich über andere Apps benötige.

Answer 2

Ich bin mit Sicherheit zu, dass alles abhängig ist, aber es gibt einige Richtlinien, die befolgt werden können/sollten. Der Zweck begrenzter Kontexte sind Grenzen. Grenzen, die sich in einem Teil der Anwendung von einem anderen trennen, indem ein gut definierter Vertrag (Schnittstelle) eingeführt wird.

Ich neige dazu, BCs wie Dienste in SOA zu behandeln. Für mich bedeutet es idealerweise, dass sie physisch getrennte Anwendungen sind (Betriebssystemprozesse/IIS -Websites). Binärdateien 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 reines Böse.

Ich hoffe, das hilft.