Kiosk-Artikel

Eine gemeinsame Sprache sprechen: Vielfältige Aspekte des Domain-driven Designs

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.

Mehr Flexibilität: Hartkodierten Code verringern

Klar, die Verwendung von hartkodiertem Code geht wesentlich einfacher von der Hand: Man muss fürs Erste weniger überlegen, da der Code nur im Hier und Jetzt läuft. Zukünftige Änderungen werden mit dieser Technik hingegen erschwert. Sobald der Code um neue Funktionen oder Datentypen erweitert wird, muss er erst überarbeitet werden. Wir zeigen, mit welchen Bibliotheken, Klassen und Techniken sich hartkodierter Code reduzieren lässt.

Umfassend und ganzheitlich: Strategic Design

Domain-driven Design bietet uns mit dem sogenannten Strategischen Design eine Anleitung, wie eine Domain und damit der Problemraum fachlich erfasst und aufgeteilt werden kann. Diese Aufteilung lässt sich dann auf den Lösungsraum – die Software – übertragen. Die Fachbegriffe aus DDD, die dabei eine Rolle spielen, sind: Domain, Subdomain, Bounded Context und schließlich die Context Map für das Zusammenspiel der Bounded Contexts. In diesem Artikel werden wir diese Begriffe und unser Verständnis davon vorstellen.

Mehr erreichen mit weniger Code: Ein Einblick in Svelte

Svelte ist der neue Stern am Web-Frontend-Himmel. Es ist rasend schnell und seine minimale Bundle Size steckt andere Frameworks locker in die Tasche. Vor allem aber ist es ausdrucksstark: Minimaler Code führt zu maximalen Ergebnissen. Performancetuning durch den User mit Hilfe von Dingen wie shouldComponentUpdate? Nicht nötig. Boilerplate-Code, um eine Komponente zu erstellen? Nicht vorhanden. Gleichzeitig ist Svelte sehr umfangreich. Ein Animationspaket und eine State-Management-Lösung sind bereits enthalten. Wie schafft Svelte das? Darauf wollen wir in diesem Artikel einen Blick werfen. Gemeinsam machen wir die ersten Schritte mit Svelte und bauen die Mutter aller Apps: eine To-do-Liste.

Lock & Crete: Upgraden von ReadWriteLock

Die Java-Klasse ReentrantReadWriteLock kann einen Read Lock nicht auf einen Write Lock upgraden. Kotlins Erweiterungsfunktion ReentrantReadWriteLock.write() schummelt ein wenig, indem sie den Read Lock vor dem Upgrade loslässt und so die Tür für Race Conditions öffnet. Eine bessere Lösung ist StampedLock, das über eine Methode verfügt, mit der versucht wird, den Lock in einen Write Lock umzuwandeln.