Seite 2: Abhängigkeiten mit einer Systemlandkarte aufzeigen

Vor der Umstellung kommt die Analyse. Die alte Anwendung, das KISS, war einmal gedanklich zu zerlegen, und zwar in die fachlichen Unternehmenskomponenten und in die technologischen Aspekte dahinter. Datenströme sowie Abhängigkeiten innerhalb der Anwendung und deren Flussrichtungen von und zu anderen Anwendungen waren ein Kern dieser technischen Analyse. In einer Systemlandkarte (s. Abb. 1) wurden alle Anwendungen und deren Bestandteile gesammelt und dadurch Abhängigkeiten aufgedeckt. Die Karte ermöglicht das Darstellen von Datenproduzenten, -konsumenten und -transport.

Eine konsumierende Anwendung lässt sich dabei in der Regel einfacher herauslösen als eine produzierende, da kein Datenfluss über Anwendungs- und damit meistens über Teamebene zu kommunizieren ist. Insbesondere bei gewachsenen Anwendungen kann die Art des Datentransports über die Zeit, je nach Stand der Technik und des Wissenstandes im Team, auf unterschiedliche Weise implementiert sein und sollte bei der Betrachtung mit einbezogen werden. In diesem Fall hilft Domain-driven Design (DDD) und insbesondere die fachlich abgrenzbaren Kontexte (in DDD: Bounded Contexts), um die Software-, System- und Team-Landschaft aufzuteilen. Dabei erkennt man schnell, welche Anwendungen und Endpunkte eine zentrale Rolle spielen. Weiterhin wird ersichtlich, welche Endpunkte abgelöst werden können und ob die Art der Serialisierung homogener und zukunftssicher gestaltet werden kann.

Kommunikation zwischen den Anwendungen mit Domain Events

Da Studitemps in der Softwareentwicklung als Vorgehensmodell Domain-driven Design (DDD) etabliert hat, setzt die Entwicklung in der Kommunikation der Anwendungen, und auch innerhalb einer Anwendung, auf Domain Events. Das sind fachliche Ereignisse, die Aktionen im Domänenmodell beschreiben.

Studitemps tauscht Domain Events oftmals nicht nur zwischen den Domänen aus. Sie dienen auch der Kommunikation zwischen den Anwendungen der verschiedenen Scrum-Teams.Die Veröffentlichung der (serialisierten) Domain Events geschieht per RabbitMQ als Message Broker zum Nachrichtenaustausch über fest definierte Exchanges. Im Anschluss lassen sie sich von den verschiedenen Anbindungen (eigenständig) über angebundene Queues konsumieren. Zu Dokumentationszwecken hat sich ein Git-Repository durchgesetzt, das die Projektbeteiligten mit Beispielen zu serialisierten Domain Events und Dokumentationen anhand von Markdown-Dateien füllen. Über Pull-Request lassen sich neue Vorschläge einreichen und kommentieren. In den meisten Fällen hat sich eine teamübergreifende Code-Review etabliert. Den ersten Entwurf des Domain Event legt das Team des produzierenden Systems an, und die Teams der konsumierenden Anwendungen beteiligen sich an der Diskussion. Der rege Austausch räumt frühzeitig Missverständnisse aus dem Weg und sorgt für einen stabilen Stand im Repository, der enorm wichtig ist, da die JSON-Dateien gleichzeitig als Test-Fixtures zum Einsatz kommen.

{
  "@type": [
   "https://studitemps.tech/specification/auftragszuordnung/arbeitszeit-zu-auftrag-zugeordnet",
    "https://studitemps.tech/specification/domain-event"
  ],
  "@id": "tech.studitemps:auftragszuordnung:arbeitszeit-zu-auftrag-zugeordnet:e7f4e458-3da6-427d-88e3-227bbad22062",
  "caused_by": "tech.studitemps:studentenzeiterfassung:urspung-foo-bar:e52c1d72-77e4-4813-9e6b-632cc454c86f",
  "correlates_with": "tech.studitemps:studentenzeiterfassung:gemeinsam-erstelltes-event-foo-bar:aaaa6b0f-d852-4a24-9e99-d254b16fdb85",
  "enacted_by": "tech.studitemps:studentenverwaltung:student:3df9132d-0732-4ed9-b380-0d8513f59804",
  "occurred_at": "2020-05-13T10:00:00+02:00",
  "dokumentiert_arbeitszeit": {
    "@id": "tech.studitemps:studentenzeiterfassung:arbeitszeit:f4715430-70b8-0136-1580-54e1ad118e9f",
    "fand_im_auftrag_statt": "tech.studitemps:auftragserstellung:auftrag:12345"
  }

Da die Anwendungen in der Regel eine PostgreSQL-Datenbank verwenden, werden die Domain Events derzeit auch jeweils in dieser abgelegt (Event Store).

Nachteil an diesem Ansatz ist, dass entweder APIs (z. B. eine RESTful HTTP API) zur Verfügung gestellt oder die Domain Events weitere Male per RabbitMQ veröffentlicht werden müssen, wenn eine Anwendung diese konsumieren möchte, aber die Events bereits publiziert sind. Das kann ein gewünschtes Verhalten sein, wenn eine neue Anwendung in die Systemlandschaft integriert wird oder in einem Fehlerfall keine korrekte Abarbeitung gewährleistet war. Ein schneller Erkenntnisgewinn setzt bei der Wichtigkeit der einmaligen Abarbeitung von Domain Events ein. Das ist besonders bei einer wiederholten Veröffentlichung der Fall. Wenn ein angebundenes System als Ergebnis beispielsweise eine E-Mail verschickt, dann würde es diese jedes Mal versenden, wenn das eindeutige Domain Event wiederholt eingespielt wird.