Matthias Eschhold

Information & Communications Technology

Softwarearchitektur Domain-Driven Design

Stuttgart, Baden-Württemberg, Germany

Matthias Eschhold

Novatec Consulting GmbH, Softwarearchitect and Trainer


Matthias Eschhold is a software architect and managing consultant at Novatec Consulting GmbH. As a Domain-driven design enthusiast and expert in structural software quality, he supports customers in their architectural work in agile application development.
What makes him special - Matthias has profound experience in the design of software architecture for product lines, which he uses with well-known customers. He also passionately imparts his architecture knowledge as a trainer "on the job" or in the context of the iSAQB Foundation Level.
His business career path and a degree in business informatics are foundation to his methods : he thinks primarily from a business perspective and only secondarily from a technical point of view. These are the best prerequisites that ensure individual approach to each client, when it comes to introduction and application of domain-driven design, in the specific company or project context.

Matthias Eschhold

DE

Matthias Eschhold ist Softwarearchitekt und Managing Consulting bei der Novatec Consulting GmbH. Als Domain-driven Design Enthusiast und Experte für strukturelle Softwarequalität unterstützt er Kunden bei der Architekturarbeit in der agilen Anwendungsentwicklung und schreibt hierbei selbst aktiv Code.
Das Besondere – Matthias verfügt über fundierte Erfahrung in der Ausgestaltung der Softwarearchitektur für Produktlinien, die er bei namhaften Kunden zum Einsatz bringt. Außerdem vermittelt er als Trainer „On the Job” oder im Rahmen des iSAQB Foundation Level leidenschaftlich sein Architekturwissen.
Sein beruflicher Werdegang über die Wirtschaft und ein Wirtschaftsinformatik Studium hin zur IT, erklären seine Herangehensweise: er denkt primär fachlich und erst im zweiten Schritt technisch. Beste Voraussetzungen, seine Kunden individuell bei der Einführung und Anwendung von Domain-driven Design im spezifischen Unternehmens- bzw. Projektkontext zu beraten.

Current sessions

Package Structures of Software Systems EN

The package structure you choose has a great influence on the architecture and maintainability of your software system. It lays the foundation for whether your application remains manageable in the long term or becomes a big ball of mud. In this talk, we will show what matters.

The package structure is the basic structure of object-oriented software systems. It is not only the way of grouping classes, but also relevant for every developer in the course of their daily work. Package structures help to quickly grasp and understand structures within the application. Is it possible to derive the functionality based upon the package name and to talk about the system on the functional level? A meaningful structuring of the application helps in the daily work, in the implementation of new requirements and in maintenance. This is due the fact, that a higher implementation speed can be achieved. In many projects, the package structure is based on the stereotypes of classes such as controllers, services or factories. This technical structuring is an intuitive procedure in smaller software systems, which leads to considerable disadvantages in larger software systems like an increase of technical depts. Reasons for that are the resulting lack of system understanding which leads to unclear responsibilities, undesired dependencies, cycles and high complexity. Finally, this causes applications to erode unnoticed resulting in a reduction of productivity.

An alternative way of system decomposition helps to avoid the listed negative effects. This will be discussed looking at use cases, which everyone can understand, and which illustrate real business transactions.


Sauber und flexibel - Flexibilitätsanforderungen erheben und mit der Clean Architecture realisieren DE

In der Softwareentwicklung versteckt sich der Wunsch nach Flexibilität in zahlreichen funktionalen und nicht-funktionalen Anforderungen. Diese oft impliziten Anforderungen müssen durch Methoden wie z.B. Qualitystorming explizit herausgearbeitet werden. Ist bekannt welche Anforderungen erfüllt werden müssen, können auch gezielt die richtigen Prinzipien und Muster für den Architekturentwurf antizipiert werden.
Die Clean Architecture verspricht eine Entkopplung der fachlichen Domäne von technischen und infrastrukturellen Aspekten. Dies ist die Basis für eine flexible Softwarearchitektur. Weiter sind die Architekturelemente Port und Adapter ein Mittel, um beispielsweise eine flexible Integration externer Services zu realisieren.
Und in Kombination mit weiteren Entwurfsmuster, entstehen in der Clean Architecture Lösungsmöglichkeiten, mit denen Sie Flexibilitätsanforderungen organisatorischer, fachlicher und struktureller Natur erfüllen können!
In diesem Vortag zeige ich Ihnen am konkreten Beispiel, wie Sie Anforderungen dieser Art als Architekt erheben und diese dann gezielt in der Architektur adressieren. Hierfür betrachten wir Qualitätsszenarien, Ringe, Pakete, Klassen, Stereotypen sowie Entwurfsprinzipien und -muster. Sie erhalten ein tiefgehendes Verständnis, wie Sie bei sich im Projekt das Clean Architecture Pattern für mehr Flexibilität realisieren können.


Domain Driven Rearchitecting mit dem "Domain-from-Legacy" Canvas DE

Wartbarkeit ist ein abstrakter Begriff und selbst wenn man sich die Definition vor Augen führt, bleiben noch Fragen offen. Am besten kann Wartbarkeit verstanden werden, wenn die tägliche Arbeit davon betroffen ist und die bestehenden Systemstrukturen kein professionelles und effektives Entwickeln von Software mehr ermöglicht. Manager und Entwickler kennen dieses Phänomen, dass aufgrund der fehlenden Wartbarkeit eine reduzierte Produktivität zu beobachten ist. Sind Sie regelmäßig Fire Fighter in stark erodierten Systemen mit einer gewachsenen Architektur, beschäftigen Sie sich vermutlich mit der Frage, wie bestehende Systeme mit einem hohen Grad an technischen Schulden, wieder auf den rechten Weg zurückgebracht werden können.
In diesem Vortrag zeige ich wie mit Domain Driven Design Anwendungsarchitektur modernisiert werden kann. Das zu Grunde liegende reale Beispiel zeigt eine Transformation von einer monolithischen, in technische Schichten organisierte Architektur, zu einer in Domänen strukturierten und fachlich ausdrucksstarken Anwendungsarchitektur. Die Restrukturierung und das Beseitigen der technischen Schulden, stellte die ursprüngliche Produktivität des Entwicklungsteam wieder her. Das System wurde wieder verständlich und wartbar.
Domain Driven Design diskutieren wir aktiv anhand der Probleme der bestehenden Architektur. Lassen Sie sich inspirieren von einem pragmatischen Ansatz der Architekturmodernisierung anhand des „Domain-from-Legacy“ Canvas und den Mustern von Domain Driven Design.


Paketstrukturen von Softwaresystemen DE

Die Paketstruktur ist eine der grundlegenden Strukturierungsmittel von objektorientierten Softwaresystemen. Sie bildet nicht nur die Basis zur Gruppierung von Klassen, sondern ist auch für jeden Entwickler im Rahmen der täglichen Arbeit relevant. Paketstrukturen helfen Strukturen innerhalb der Anwendung schnell zu erfassen und zu verstehen. Ist es möglich die Fachlichkeit anhand des Paketnamen abzuleiten und auf der fachlichen Ebene über das System zu sprechen? Eine sinnvolle Strukturierung der Anwendung hilft bei der Umsetzung von neuen Anforderungen und bei der Wartung, weil dadurch eine höhere Umsetzungsgeschwindigkeit erzielt werden kann. In vielen Projekten orientiert sich die Paketstruktur anhand der dort abgelegten Stereotypen, wie Controllern, Services oder Factories. Diese technische Strukturierung ist in kleineren Softwaresystemen ein intuitives Verfahren, welches in größeren Softwaresystemen zu erheblichen Nachteilen führt. Grund dafür ist, dass das daraus resultierende mangelnde Systemverständnis zu unklaren Verantwortlichkeiten, ungewünschten Abhängigkeiten, Zyklen und hoher Komplexität führt. Letztendlich bewirkt dies, dass Anwendungen oft unbemerkt erodieren und technische Schulden aufgebaut werden. Diese technischen Schulden führen auf lange Sicht zu einer Reduktion der Produktivität. Eine alternative Art der Systemdekomposition hilft die aufgeführten negativen Effekte zu vermeiden. Eine Orientierung am mentalen Modell des Nutzers bzw. Entwicklers, führt zu einer sogenannten funktionalen Systemzerlegung. Diese wird diskutiert an Anwendungsfällen, die jedermann verstehen kann und reale Geschäftsvorfälle abbilden.


Agile Produktlinienarchitektur als Supporter agiler Transformation DE

Die agile Transformation ist von vielen Erfolgsfaktoren abhängig. Softwarearchitektur ist einer dieser Erfolgsfaktoren. Sie entscheidet darüber, ob ein System langfristig wartbar und flexibel ist. Darüber hinaus entscheidet die Architektur darüber, ob ein System der agilen und hohen Entwicklungsgeschwindigkeit standhalten kann.

Softwarearchitektur kann falsch gelebt blockieren. Keine Softwarearchitektur führt aufgrund Qualitätsmängel früher oder später auch zum Stillstand. Softwarearchitektur agil und evolutionär gelebt, kann nicht nur Unterstützen sondern auch Beschleunigen und agile Entwicklungsteam ermächtigen erfolgreich ihren Weg zu gehen!

Wenn Softwarearchitektur als mehr als Konzeption und Technologie aufgefasst wird und sich die Architekturarbeit einem wert-orientierten und kollaborativen Ideal verschreibt, dann kann Softwarearchitektur zu etwas gänzlich anderem werden! Und zwar zu einem modernen architektonischen Führungsinstrument auf Basis einer Makroarchitektur mit dem Ziel Entwicklungsteams der Produktlinien zu empowern! Team Autonomie, Agile Werte und Kollaboration stehen dabei an oberster Stelle.

Klingt das für Sie verrückt? Das kann ich verstehen, aber das ist es nicht. Ist es einfach? Nein, natürlich nicht! Es ist die praktische Anwendung der Ideen von Agilität, Evolutionärer Softwarearchitektur, sozio-technischer Architektur und von bekannten Vorgehensmuster für kollaborative Zusammenarbeit. Lassen Sie uns über Softwarearchitektur sprechen und dabei den Menschen, Teams und moderne architektonische Führungsinstrumente in den Vordergrund stellen. Am Ende von diesem Vortrag verstehen Sie die Wichtigkeit agiler Werte und Kollaboration in der Architekturarbeit und kennen Methoden, um dies effizient in der Praxis anzuwenden. Lassen Sie sich inspirieren für ihre Softwarefabrik und lernen wichtige Fassetten von Softwarearchitektur im agilen Kontext kennen.

Wenn Softwarearchitektur als mehr als Konzeption und Technologie aufgefasst wird und sich die Architekturarbeit einem wert-orientierten und kollaborativen Ideal verschreibt, dann kann Softwarearchitektur zu etwas gänzlich anderem werden! Und zwar zu einem modernen architektonischen Führungsinstrument auf Basis einer Makroarchitektur mit dem Ziel Entwicklungsteams der Produktlinien zu empowern! Team Autonomie, Agile Werte und Kollaboration stehen dabei an oberster Stelle.


Domain-driven Rearchitecting with the “Domain-from-legacy” Canvas EN

What is maintainability? Most developers and product owners can't answer this question even after reading official definitions because they are too abstract. Do you wonder why the sprint goal hasn't been met over and over again? Do developers experience being less productive? Congratulations, your system is probably not maintainable. If you know this all too well and are wondering what can be done to improve the situation, Domain-driven Rearchitecting could be a suitable approach for you.
On the basis of real-life examples, I will demonstrate how you could improve your architecture by following principles and patterns of Domain-driven Design. We are focusing on using the “Domain-from-Legacy” canvas. This is a collaborative and incremental method for software architecture modernization. We will start with analyzing existing code to find potential independent functional units. Lastly, we investigate these units according to DDD principles. In the end, we finalize the socio-technical architecture of the future based on bounded contexts.
Get inspired by an agile and collaborative way to modernize your architecture and make your development team productive again.

On the basis of real-life examples, I will demonstrate how you could improve your architecture by following principles and patterns of Domain-driven Design. We are focusing on using the “Domain-from-Legacy” canvas. This is a collaborative and incremental method for software architecture modernization.


Nachhaltig Wachsen mit fluiden Teams und Domain Driven Design DE

Scrum ist das Framework für die Entwicklung von Softwaresystemen in komplexen und fast chaotischen Umgebungen. Durch geschicktes Product Ownership entstehen fachlich kompetente Entwicklungsteams. Cross-Funktional aufgestellt entwickeln sie hoch-produktiv, eigenverantwortlich und erfolgreich Software.

Ist ein Produkt erfolgreich gestartet, muss alles schneller gehen und das Entwicklungsteam soll deutlich vergrößert werden! Weitere Entwickler reduzieren jedoch meistens die Produktivität des Teams. Die Kommunikation wird deutlich komplexer und die Bereitschaft der Entwickler Verantwortung zu übernehmen nimmt signifikant ab! Doch wie kann das Team jetzt sinnvoll erweitert werden?

Mit Domain Driven Design und Fluiden Sub-Teams!

DDD ermöglicht ein nachhaltiges Wachstum von Teams, ohne skalieren zu müssen. Diese Lösung wird aber von den meisten Firmen nicht erkannt. Anhand von Domänen und Subdomänen kann sich das agile Team in weniger komplexe Sub-Teams aufteilen, diese übernehmen mehr Verantwortung und arbeiten effizienter. Durch Selbstorganisation und gemeinsame Scrum Events wird das Risiko von Abhängigkeiten minimiert.

Matthias Eschhold und Nils Hyoma erzählen, wie sie in komplexen Domänen skalierbare Softwarearchitektur und Teamstrukturen von bis zu 20 Mitgliedern aufgebaut und etabliert haben. Die Mitgliedern übernahmen immer mehr Verantwortung, der Wert, die Qualität und sogar die Entwicklungsgeschwindigkeit konnten deutlich gesteigert werden.


Past and future events

iSAQB Software Architecture Gathering 2021

11 Oct 2021 - 14 Oct 2021

Java Forum Nord 2021

16 Sep 2021
Hannover, Lower Saxony, Germany