Algorithmen für spezielle Aufgaben selbst zu entwickeln, ist sehr aufwendig und fehleranfällig. Oft fehlt auch das notwendige Know-how. Der Einsatz von externen Bibliotheken ist hilfreich. Beispiele geben Anregungen für den Einsatz im eigenen Projekt. Gleichzeitig ist das Thema ein starkes Signal für die Wiederverwendung.

Softwareprojekte scheitern oft nicht an der Technik, sondern an interdisziplinärer Kommunikation, wenn es zwischen Entwicklern und Fachleuten Verständnisprobleme gibt. Sie arbeiten mit unterschiedlichen Terminologien und sprechen somit unterschiedliche Sprachen. Hilfreich ist ein einheitliches und standardisiertes Vorgehen, das Entwickler und Fachexperten integriert. Domain-driven Design (DDD) verfolgt dieses Ziel.

Seit 2012 und dem Artikel von James Lewis und Martin Fowler sind Microservices in aller Munde. Sie schienen die Antwort auf eine stets wachsende Komplexität und die Cloud zu sein. Aber mit der Zeit wurde es immer deutlicher, dass es Aufgabenstellungen gibt, die anders beantwortet werden müssen.

Blicken Sie mit uns über den Tellerrand und erfahren Sie, warum JavaScript-Projekte oft schwer zu warten sind, wie Microfrontend-Architekturen helfen können, zu langlebigen Projekt-Set-ups zu gelangen, welche Rolle das JavaScript-Modulsystem (ESM) dabei spielt und wie man es schafft, Vue, React und pure JavaScript-Komponenten in Einklang zu bringen.

Operatoren stellen einen Mechanismus zur Verfügung, um komplexe Funktionen in les- und wartbarer Weise zu implementieren. Sie bieten einen immensen Mehrwert bei der Arbeit mit RxJS. Allerdings wissen nur wenige über die interne Implementierung von Operatoren und die dahinterliegenden Gründe Bescheid.

Legacy-Code treibt die Entwicklungskosten in die Höhe und führt dazu, dass wir diese alten Softwaresysteme nicht mehr gerne anfassen. Ist das unvermeidbar? Können wir etwas tun? Mit Domain-driven Design (DDD) haben wir ein Werkzeug zur Hand, um Legacy-Code Schritt für Schritt wieder in den Bereich beherrschbarer Wartungskosten zu bringen.

Operatoren stellen einen Mechanismus zur Verfügung, um komplexe Funktionen in les- und wartbarer Weise zu implementieren. Sie bieten einen immensen Mehrwert bei der Arbeit mit RxJS. Allerdings wissen nur wenige über die interne Implementierung von Operatoren und die dahinterliegenden Gründe Bescheid.

Obgleich das Zielbild sowohl ein Monolith als auch eine Microservices-Architektur sein kann – das Axon Framework offeriert einen leichtgewichtigen Ansatz zur Implementierung Event-basierter Anwendungen. Dabei stützt sich das Framework auf gängige Muster aus dem Domain-driven Design (DDD) und begünstigt die Umsetzung einer Anwendung nach dem Architekturprinzip Command Query Responsibility Segregation (CQRS) und der Persistenzstrategie Event Sourcing. Durch diese Flexibilität und die Tatsache, dass das Axon Framework bestens mit dem Spring Framework integriert ist und damit ein quasistandardisiertes Programmiermodell unterstützt, ist es für den modernen Java-Entwickler einen Blick wert.

Im Artikel von Carola Lilienthal und Michael Plöd [1] wurde gezeigt, wie man eine Domäne in mehrere Bounded Contexts aufteilt. Dabei erhalten wir statt einem großen, schwer verständlichen und schwer wartbaren Domänenmodell nun mehrere, besser handhabbare Domänenmodelle. In diesem Teil der Serie schauen wir darauf, wie man das einzelne Domänenmodell konkret implementieren kann.

Strategic Design bietet eine etablierte Methodik zum Schneiden großer Anwendungen in möglichst autarke Domänen. Nx erlaubt die Umsetzung dieser Domänen in einem Angular Monorepo und stellt sicher, dass dabei möglichst wenig Abhängigkeiten entstehen. Ausgewählte Ideen von Tactical Design unterstützen dabei.

Bei der Entwicklung von Softwaresystemen und -architekturen gibt es verschiedene Ansätze und Paradigmen, die jeweils kontextabhängige Vor- und Nachteile haben. Zu gerne folgen wir bei der Beurteilung von Architekturen entweder unseren persönlichen Vorlieben oder wir verurteilen Lösungen, die nicht mehr State of the Art oder zu komplex sind, um sie mit überschaubarem Aufwand zu überblicken. Eine objektive Beurteilung einer gewachsenen Architektur kann aber nur auf einer strukturierten und sachlichen Analyse basieren.

Vue 3 steht in den Startlöchern. Mit dem neuen Composition API kommt eine zusätzliche Möglichkeit, um Komponenten aufzubauen. Doch warum ist das überhaupt notwendig? Welche Vorteile ergeben sich aus der Verwendung des API und wie benutzt man es?