Inhaltsverzeichnis
Die Herausforderung beim Beginn eines neuen Software-Projektes steigen Jahr für Jahr. Nicht nur möchten technische Möglichkeiten ausgereizt, sondern entsprechend hohe Investitionen langfristig angelegt werden. Hierbei stehen Software-Entwickler und -Architekten vor der Herausforderung, Systeme so modular wie möglich, aber auch so schnell wie möglich umzusetzen.
Ein Ansatz, welcher bei der Umsetzung größerer oder betriebskritischer Software-Projekte zum Einsatz kommt ist das so genannte Event-Driven-Design (EDD).
Was ist “Event-Driven”?
Im Grunde betrachtet man bei dem Aufbau einer ereignisgesteuerten Architektur die einzelnen Ereignisse und Aktionen, die in sämtlichen Komponenten der umzusetzenden Software vorkommen können.
Betrachtet man sich das Beispiel zum Beispiel eines CRM-Systems, könnte man unter Anderem folgende Ereignisse feststellen:
- Erstellen eines Kunden
- Ändern eines Kunden
- Senden einer Nachricht an Kunden
- z.B. via SMS, Mail, etc.
- Empfang von Nachrichten (z.B. E-Mails, Ticket-System) und Zuordnung zum Kunden
- Verknüpfen von Aufträgen, Angebote, etc.
Diese Ereignisse betreffen Aktionen, welche sowohl aus der Benutzeroberfläche oder durch externe Systeme (z.B. einem Dokumentenmanagement-Systems) aufgerufen werden können.
Ziel beim Event-Driven-Design ist es jedoch, möglichst viele dieser Ereignisse und Aktionen über einen zentralen Event-Hub laufen zu lassen. Dies kann z.B. eine Message-Queue sein. Dadurch ist man in der Lage diese Ereignisse zu abstrahieren und dedizierte Dienste (z.B. für das Verarbeiten von Stammdatenänderungen) zu beschreiben.
Warum aber diese Abstraktion?
Ein Vorteil dieser Abstraktion ist, dass unterschiedliche Systeme, welche teils mit unterschiedlichen Frameworks, Sprachen oder Datenquellen arbeiten über diese definierten Events und der Anbindung an die Message-Queue keine anderen Schnittstellen nutzen müssen. Sie werden also im Entwicklungs- und Produktzyklus nicht gezwungen, einzelne Schnittstellen der jeweiligen anderen Systeme und Komponenten umzusetzen. Nicht jede Server-Komponente, welche also eine Mail versenden muss, muss zwingender-maßen eine SMTP-Schnittstelle bedienen können.
Hierbei recht es also einen “Mail”-Dienst in die Architektur aufzunehmen, welcher über die Message-Queue auf entsprechende “Versandaufträge” hört und diese entsprechend ausführt. Ob der Ersteller dieses Events nun eine .NET, NodeJS oder Java-Anwendung ist, ist für den Mail-Dienst demnach völlig irrelevant.
Weitere Vorteile von verteilten Architekturen
Durch die Kommunikation und Auslösung von Aktionen über Message-Queues werden langfristig, nachhaltige Vorteile geschaffen, die sich bei wachsenden Systemen schnell bezahlt machen.
Nehmen wir an, dass das System eine betriebskritische Anwendung darstellt. Hier können Sie wichtige Dienste mehrfach auf unterschiedlicher/verteilter Hardware ausführen, um so ein geclustertes Umfeld zu schaffen und eine Ausfallsicherheit zu garantieren. Jedes Event wird durch branchenübliche MessageQueues gesichert an einen hörenden Endpunkt übergeben - dadurch wird eine Doppelverarbeitung verhindert.
Jetzt starten!
Wir können Sie beim gezielten Aufbau und Umsetzung einer verteilten Systemanwendung bedarfsgerecht unterstützen. Hierbei empfehlen wir Ihnen unseren Schulungen “Schlungskatalog”, welchen Sie individuell für Ihr Team buchen können.
Alternativ können wir Sie auch bei der Konzeption und Architektur entsprechend projektbezogen unterstützen, sowie entsprechendes Know-How aufbauen.
Bereiten Sie also schon heute alles für nachhaltige Software-Architekturen vor und kontaktieren Sie uns. Wir freuen uns von Ihnen zu hören.