Bei der Arbeit haben wir ein benutzerdefiniertes Legacy-CRM-System (im folgenden Text als LS bezeichnet), das vom Unternehmen verwendet wird. LS wird auch zum Speichern einiger Kundenzahlungen verwendet. LS ist ausgelagert und mein Unternehmen ist nicht Eigentümer des Codes, daher kann mein Unternehmen keine (direkten) Änderungen am Anwendungscode vornehmen. Was uns jedoch gehört, ist die von LS verwendete Datenbank und ihre Daten. Die Art und Weise, wie Daten verwaltet werden, nutzt eine einzige Datenbank und eine riesige Menge an Tabellen, in denen Informationen gespeichert sind, die für mehrere Sektoren benötigt werden (Beispiel: Vertrieb, Finanzen, Marketing usw.). Dies führt zu einem komplexen Beziehungsdiagramm und schwer verständlichen Tabellen.
Jetzt haben wir eine weitere Anwendung (im folgenden Text wird sie als ConfApp bezeichnet). wurde intern entwickelt und nutzt Teile der Daten von LS, damit der Finanzsektor eine Art Kundenzahlungsbestätigung für unsere Kunden generieren kann. Die ConfApp wird auch von der Buchhaltung verwendet, auch für Kundenzahlungsbestätigungen für unsere Kunden, aber die Buchhaltung hat andere Bedürfnisse und Anforderungen als die Finanzabteilung. Im DDD-Jargon können wir sagen, dass es zwei verschiedene Bounded Contexts gibt, einen für die Buchhaltung und einen für die Finanzen.
Im Moment fragt die ConfApp die LS-Datenbank ab direkt, um die benötigten Daten über die Kunden und die Zahlungen abzurufen. Da die LS-Datenbank direkt abgefragt wird, ist die ConfApp fest mit der Datenbank verbunden und muss über Spalten und Beziehungen Bescheid wissen, die sie nicht interessieren, sowie über alle Änderungen an der LS-Datenbank. Aus diesem Grund möchte ich gemäß den DDD-Praktiken für jeden begrenzten Kontext in der ConfApp-Datenbank ein separates Schema erstellen. Jedes Schema hätte eine Client-Tabelle, aber nur die Informationen, an denen dieser bestimmte begrenzte Kontext interessiert ist (z. B. benötigt die Buchhaltung einen Satz E-Mail-Adressen für Kunden, während die Finanzabteilung einen anderen Satz E-Mail-Adressen benötigt). Um dies zu erreichen, muss ConfApp in LS integriert werden. Das Problem, mit dem ich konfrontiert bin, besteht darin, dass ich nicht weiß, welche Art von Integration ich verwenden soll, da der LS nicht geändert werden kann.
Optionen, an die ich gedacht habe, sind die Folgendes:
1. Messaging => erscheint kompliziert, da ich nur Daten und kein Verhalten benötige. Außerdem könnte es schwierig werden, da, wie bereits erwähnt, eine direkte Änderung des LS-Quellcodes nicht möglich ist. Vielleicht erstellen Sie eine Art Adapteranwendung, die sich mit der Datenbank von LS verbindet und bei Änderungen Nachrichten an Abonnentenanwendungen sendet. Scheint trotzdem kompliziert zu sein.
2. Datenbankintegration => Änderungsverfolgung oder eine andere Methode zur Datenbankänderungsverfolgung. Sollte einfacher sein als Option 1, löst das Problem, nur die Daten abzurufen, die die ConfApp benötigt, löst aber nicht das Problem der Kopplung zwischen ConfApp und LS-Datenbank. Anstatt die Synchronisierungslogik durch ConfApp zu implementieren, könnte dies auch ein anderes Projekt tun, aber gibt es dann einen Grund, stattdessen nicht Messaging zu verwenden? Welche Art von Datensynchronisierungsmethode soll außerdem verwendet werden? Bei beiden Systemdatenbanken handelt es sich um SQL Server-Instanzen.
Dutzende anderer Anwendungen folgen diesem Muster der Integration mit LS, daher muss auch eine Lösung für diese Systeme angewendet werden. ConfApp benötigt keine „Echtzeit“-Daten, sie können bis zu 1 Monat alt sein. Einige andere Systeme benötigen Daten, die aktueller sind (z. B. von gestern). Ich habe in der Praxis noch nie mit Messaging gearbeitet. Sieht für mich nach einer übertriebenen Lösung aus.
Ist die Systemintegration mithilfe von Nachrichten zwischen diesen beiden Systemen (und möglicherweise anderen) übertrie ⇐ C#
-
- Similar Topics
- Replies
- Views
- Last post