Warum die Architektur einer Software so wichtig ist
Die klassische Architektur dient als illustrierender Vergleich. Vieles dort ist zur Software-Architektur kompatibel. Was besonders einfach nachvollziehbar ist: Bei einem klassischen Bauwerk erwartet niemand als allerersten Schritt, dass Zement angerührt wird. Stattdessen werden in einer umfangreichen Analysephase unter Zielsetzungen und Randbedingungen, z.B. zur Baugrundbeschaffenheit, Bedarfe und Möglichkeiten zum Bauwerk evaluiert. Es folgt eine detailreiche Planungs- und Entwurfsphase mit einer Vielzahl an Architekturplänen, Schnitten, Detailzeichnungen, 3D-Visualisierungen und genauen Ablaufplänen. Alles das passiert lange vor dem ersten Spatenstich.
Bei der Softwareentwicklung erwarten wir als Software-Architekten von unseren Kunden dasselbe Grundverständnis: Eine nachhaltige, funktionale und saubere Software hat nur zu einem Teil mit Coding, dem Tastenklappern, zu tun. Der weitaus wichtigere Teil dafür liegt in der Software-Architektur: Sie formt und regelt das strukturelle Zusammenspiel aller Komponenten und Systembestandteile und bildet damit das innere Gerüst und den Rahmen dafür, dass die entstehende Softwareanwendung funktional, robust, anwendbar, wartbar und erweiterbar wird.
Und wie die Architektur eines klassischen Bauwerks vor Baubeginn festgelegt sein muss und Einfluss auf die Bauphasen, die Nutzung und die Weiterentwicklungsmöglichkeiten des Bauwerks hat, ist die Software-Architektur ebenso grundlegend, um die entstehende Software ohne anwachsende technologische Schulden weiterzuentwickeln. Das gilt übrigens umso intensiver, je mehr eine Software in agilen Iterationen entsteht.
Diese Erkenntnis teilen Sie? Lassen Sie uns miteinander sprechen!
Software-Architektur in a Nutshell
Damit mit der Entwicklung einer Software für einen speziellen Anwendungszweck weder das Rad neu erfunden, noch die Zukunft verbaut wird, ist in der Softwareentwicklung eine Architekturfindung essentiell. customQuake nutzt moderne, aber gängige Methoden, um eine solche Architektur mit den Erkenntnissen aus der Anforderungsanalyse herauszuarbeiten. Für die Umsetzung nutzen wir, wo es sinnvoll und möglich ist, vorhandenes Know how in Form von Open Source Frameworks und fügen selbstgeschriebene Servicekomponenten hinzu. Ziel ist immer, die Anwendung nach dem Onion-Principle um eine Domäne herum geschäftsprozesszentriert aufzusetzen und die Anwendung unabhängig von spezifischen Technologien zu machen. Reine Technologie (z.B. eine Datenbank, eine Ausgabeform) sollte im Lebenszyklus der Software jederzeit leicht austauschbar bleiben, um sich verändernden Anforderungen anpassen zu können.
Unsere Leistungen
Moderne Software-Architekturen
Mit der ersten Zeile Code ist Software nicht mehr neu. Das ist eine triviale und gleichzeitig wichtige Erkenntnis. Moderne Software-Architektur ist nicht nur hip, sondern die Grundlage für langlebige, robuste, wartbare und erweiterbare, aber auch intuitiv nutzbare Software-Systeme. Damit Software nachhaltig ist, müssen Sinn, Zweck und Ziel verstanden sein. Lange Zeit dominierten technische Datenstrukturen die Entwicklung. Moderne Architekturen stellen Ihre Geschäftsprozesse wieder in den Vordergrund. Sie berücksichtigen den steigenden Bedarf nach reaktiven Systemen, die Ihre Benutzer jederzeit bei ihrer Arbeit unterstützen.
Wir verstehen zuerst die Anwendung, dann bauen wir sie.Domain-Driven Design
Viele Komplexitäten und Herausforderungen in der Softwareentwicklung entstehen dadurch, dass sich Softwareentwickler und Fachabteilung nicht verstehen. Mit Domain-Driven Design entwerfen Entwickler idealerweise zusammen mit der Fachabteilung das System. Gemeinsam entwickeln sie eine Sprache (Ubiquitous Language, die allgegenwärtige Sprache), die alle verstehen. Das senkt die Kommunikationshürde und sorgt dafür, dass die Umsetzung auch tatsächlich den Vorstellungen der Fachabteilung entspricht.
Domain-Driven Design stellt Ihre Geschäftsprozesse in den Vordergrund.CQRS
In den meisten Fällen sind es Probleme bei der Dateneingabe durch Benutzer oder externe System, die ein System beeinträchtigen. Der überwiegende Anteil an Systemaufrufen betrifft hingegen die Datenausgabe. Moderne Architekturen trennen daher mit dem CQRS-Pattern (Command-Query-Responsibility-Segregation) ändernde und ausgebenden Aktionen.
Performante Software kommt ohne CQRS nicht aus.Event-Sourcing
Datenmodellzentrierte Entwicklung basiert meistens auf dem CRUD-Pattern (Create, Read, Update, Delete) und dem Überschreiben von Zuständen. Auf der Strecke bleiben dabei die Veränderungshistorie und die Prozesse. Event-Sourcing ist ein Architekturmuster, bei dem nicht Zustände, sondern Veränderungen gespeichert werden und jeder Veränderung eine fachliche Bedeutung gegeben werden kann. So lässt sich jederzeit nicht nur nachvollziehen, was geändert wurde, sondern auch warum es geändert wurde.
Event-Sourcing macht auditierbare Systeme möglich mit jederzeit reproduzierbaren Systemzuständen.