DDD - Anmeldeinformationen für externe Kontexte

Question

Meine Anwendung automatisiert einige Aktionen auf einem externen System im Auftrag des Benutzers. Nennen wir diesen Kontext meiner Anwendung Inventar BC.

Da dies eines der Hauptmerkmale meiner Anwendung ist, wird es als Domain-Service modelliert und mit einer Anti-Korruptionsschicht implementiert. Alles soweit großartig.

Auch der Benutzer möglicherweise ein paar verschiedene Konten auf diesem externen System, das meine Anwendung für sie behandelt. Also habe ich einen separaten beschränkten Kontext, in dem ich die Benutzerdetails und ihre Konto-IDs vom externen System behalte. Sagen wir Identität BC.

Jetzt muss die Antikorruptionsebene von Inventory BC die Konto-ID und die Anmeldeinformationen des externen Systems verwenden. Die Konto-ID ist Teil von Inventar-BC, um die externen Konten und Vorgänge zu trennen, die für diese externen Konten nicht möglich sind. Aber ich bin mir nicht sicher, wo ich die Anmeldeinformationen speichern und sie aus der Inventar-ACL abrufen soll.

Sollte ich die Credentials entlang ihrer Konto-IDs in der Identity BC behalten? Dann könnte ich einen Anwendungsdienst erstellen, um die Anmeldeinformationen für eine bestimmte Konto-ID zurückzugeben und sie aus der Inventar-ACL aufzurufen.

Oder gibt es eine bessere Praxis?

Edit1: Auch, wenn ich alle meine Kontexte in einen zusammenfalten sollte, was wäre angemessen?

Edit2: Auf meinem Domain-Service für das externe System sollten Anmeldeinformationen Teil der Methode params sein? Oder sollte ich mit einer Lösung fortfahren, die die Anmeldeinformationen auf der ACL-Ebene enthält?

Answer 1

Es ist alles ein wenig verschwommen, aber die externen Systemanmeldeinformationen in Identity BC neben den Benutzerdaten Ihres Systems zu haben, fühlt sich an wie eine undichte Abstraktion. Ist das nicht eine Antikorruptionsebene, die genau davor schützen soll?

Wenn Sie bedenken, dass es die Aufgabe der ACL ist, sich von Ihrer Welt an die Welt des externen Systems anzupassen, würde ich sagen, dass es auch Ihre Aufgabe ist, von Ihren IDs zu ihren IDs zu mappen, und nur sie sollte Zugriff auf die externe haben IDs. Wie und wo diese IDs gespeichert werden, ist ein technisches Detail. Vielleicht ist es bequemer, sie in derselben DB-Tabelle wie Ihre internen IDs zu speichern. Aber ich denke, sie sollten nicht Teil der Identity BC sein.