Softwareentwicklung: Definition der Architektur oder Arbeit innerhalb einer bestehenden.

Ich arbeite seit mehr als fünfundzwanzig Jahren in der Softwareentwicklung. Das Microsoft-Ökosystem ist mein Hauptreferenzpunkt, neben den Webtechnologien, die jedes Projekt benötigt.

Auf der Backend-Seite arbeite ich hauptsächlich mit .NET und ASP.NET Core: APIs, Anwendungsregeln, Daten und Integrationen. Ich bin der Plattform von .NET Framework bis zu den aktuellen .NET-Versionen gefolgt und habe für kleine und mittelständische Unternehmen sowie in Unternehmensumgebungen gearbeitet.

Auf der Frontend-Seite habe ich umfangreiche Erfahrung mit Angular: zunächst AngularJS, dann Angular ab seinen frühesten Versionen. Ich habe auch React in großen Projekten eingesetzt. Das Produkt und das Team bestimmen die Wahl des Tools; in jedem Fall strebe ich an, Schnittstellen zu erstellen, die auch bei wachsender Funktionalität und Teamgröße überschaubar bleiben.

Ich beginne nicht mit dem Namen einer Architektur. Ich beginne mit den Regeln, die der Code ausdrücken muss, und den Änderungen, die er unterstützen muss.

In Modulen mit erheblicher Geschäftslogik trenne ich die Domäne, die Use Cases und die technischen Details. Die Domäne enthält die Konzepte und Geschäftsregeln des Kunden; die Anwendungsschicht koordiniert die Operationen; Datenbanken, Nachrichtenübermittlung und externe APIs sind Integrationsdetails. Dies wendet das zentrale Prinzip der Clean Architecture an: Systemregeln sollten nicht direkt von der Technologie abhängen, die zur Speicherung oder Offenlegung verwendet wird.

Ich organisiere die Arbeit oft nach Funktionen mit einem Vertical Slice Ansatz. Der Endpunkt, die Anfrage, der Handler und die Validierung für einen Use Case bleiben eng beieinander, sodass jemand, der eine Funktion ändert, ihrem Weg folgen kann, ohne entfernte Ordner durchsuchen zu müssen. Clean Architecture und Vertical Slice behandeln unterschiedliche Fragen: die erste betrifft Abhängigkeiten, die zweite die Gruppierung des Codes.

Ich setze Dependency Injection ein, um Abhängigkeiten explizit darzustellen, und trenne Befehle, Abfragen und ihre Handler, wenn dies die Anwendungsfälle klarer macht. Diese Werkzeuge erfordern Maßhalten: zusätzliche Schichten und Abstraktionen können eine einfache Funktion schwerer nachvollziehbar machen.

Die Trennung von Modulen innerhalb einer Anwendung und der Einsatz unabhängiger Dienste sind unterschiedliche Entscheidungen.

Ich erwäge Microservices, wenn die funktionalen Grenzen klar sind und ein echter Vorteil darin besteht, die Teile unabhängig weiterzuentwickeln oder zu veröffentlichen. Diese Autonomie hat ihren Preis: Netzwerkkommunikation, Fehlerbehandlung, Überwachung und Release-Koordination. In anderen Kontexten kann eine Anwendung mit gut definierten Modulen geeigneter sein.

Ich habe an Projekten gearbeitet, die Azure Service Bus oder RabbitMQ für die asynchrone Kommunikation genutzt haben. Eine Komponente kann ein Ereignis veröffentlichen, und andere können darauf reagieren, ohne dass der Produzent jeden Empfänger direkt aufruft. Diese Entkopplung erfordert Sorgfalt bei Verzögerungen, doppelten Nachrichten, Fehlern und Nachverfolgbarkeit. In bestehenden Produkten habe ich bei Integrationen geholfen und Abläufe diagnostiziert.

Wichtige Regeln sollten für Personen, die das Produkt kennen, verständlich sein und im Laufe der Zeit testbar bleiben.

Ich wende Domain-Driven Design-Ideen in dem Umfang an, den das Problem erfordert: eine gemeinsame Sprache mit Produktexperten, Grenzen zwischen funktionalen Bereichen und Geschäftsregeln, die dort platziert werden können, wo sie verstanden und getestet werden können. Nicht jede Anwendung benötigt jedes DDD-Muster.

Automatisierte Tests überprüfen das Verhalten und schützen zukünftige Änderungen. Ich wende TDD an, wenn das Schreiben eines Tests zuerst eine Regel oder einen Sonderfall eingrenzt; in anderen Situationen füge ich Tests während der Entwicklung hinzu oder reproduziere einen Fehler mit einem Test, bevor ich ihn behebe. Tests ermöglichen es auch, eine API zu überprüfen, bevor der Client bereit ist. Wo Tests für die Genehmigung eines Pull Requests erforderlich sind, folge ich den Anforderungen des Teams. Eine hohe Abdeckung garantiert jedoch allein keine guten Tests.

Die Architektur sollte einem Projekt helfen zu wachsen, anstatt ein Selbstzweck zu werden.

Ein System, das Ereignisse austauscht, benötigt nicht unbedingt Event Sourcing. Bei Event Sourcing bilden Ereignisse eine dauerhafte Geschichte, aus der der Zustand des Systems wiederhergestellt wird. Dies kann helfen, wenn die Entwicklung eines Prozesses erhalten bleiben muss, aber es erfordert Arbeit rund um die Versionierung, Projektionen und langfristiges Management. Ich würde es nur für einen konkreten Bedarf in Betracht ziehen.

Ich wende das gleiche Kriterium auf Schichten, Muster und verteilte Dienste an: Beginnen Sie mit einer angemessenen Struktur und entwickeln Sie sie weiter, wenn Regeln, Grenzen oder Lasten eine elaboriertere Lösung rechtfertigen. In Projekten, die ich leite, übernehme ich die Verantwortung für diese Entscheidungen; wenn ich an jemandes Produkt arbeite, helfe ich, es innerhalb der Verantwortlichkeiten und Einschränkungen des Teams zu verbessern.