Focus

Beim strategischen Domain-Driven Design fokussieren wir uns in der Modellierung sehr stark darauf, die Fachlichkeit möglichst passend zu identifizieren und im Design abzubilden. Leider verlieren wir Entwickler bei der technischen Umsetzung diesen fachlichen Fokus dann aber allzu oft wieder aus den Augen und lassen uns (zu) stark vom neusten hippen Framework begeistern, leiten und beeinflussen und verschmutzen so das fachliche Modell mit unzähligen Technologien.

Article

Command & Control, SAFe, Domain-driven Design, and Release Trains

Handling Complex Software Projects

Article

Identification of quality requirements with Quality Storming

In various communities, several methods for the collaborative modeling of business requirements have been established in recent years. Well-known examples are EventStorming or Domain Storytelling. These approaches are based on achieving a better shared understanding of the business requirements in an interdisciplinary way. But what about the requirements for the quality of the software being developed? Especially here, a collaborative approach is immensely important in order to avoid chasing after imperfect ideals that cause the costs and complexity of products to explode. This is where the workshop format Quality Storming comes in, which I would like to introduce in the course of this article.

Blog Post

code-your-model

Some time ago I was looking for some simple, lightweight tool to document a complex, modularized model. I was not able to find anything that fits my requirements or expectations, so I came up with my own idea. Today, a good 15 months later, I want to introduce it to you.

Article

Cloud-native, Microservices, Domain-driven Design, Kubernetes

Alles nur ein Hype?

Blog Post

Event Storming und Domain Story Telling - Ein Vergleich

„Knowledge Crunching“ nennt Eric Evans die wichtigen Gespräche mit Domänenexperten, die in seinem Buch „Domain-Driven Design“ zu tieferem Verständnis der Fachdomäne führen sollen. In den letzten Jahren haben sich für diese Gespräche zwei moderne Workshopformate etabliert: „Event Storming“ und „Domain Storytelling“. Beide Formate eignen sich um Projektbeteiligten IT-Mitarbeitern einen tiefen Einblick in die Fachdomäne geben und ein gemeinsames visuelles Modell der Domäne zu entwickeln. Dennoch haben beide Formate unterschiedliche Stärken und Schwächen, die ich in diesem Artikel herausarbeiten möchte.

Blog Post

Cooking with Onions: Inward-Pointing Arrows

Some violations of our architectural principles are easy to spot. Others hide in plain sight, and neither static analysis nor a shallow code review will help you spot them.

Blog Post

Domain Events vs. Event Sourcing

Why domain events and event sourcing should not be mixed up

Blog Post

Domain Events vs. Event Sourcing

Weshalb Domain Events und Event Sourcing nicht vermischt werden sollten

Blog Post

Was ist ein Domain-driven Design Architektur-Kata?

Architektur-Katas sind ein sehr interaktives Trainingsformat. Sie eignen sich hervorragend, um Domain-driven Design (DDD) zu vermitteln.

Blog Post

Schubladendenken - aber konstruktiv

Verwendung von Stereotypen im Code als Basis für ein gemeinsames Architekturverständnis - und mehr

Blog Post

Domain Exceptions?

In jedem Softwaresystem kommt es zu Ausnahmesituationen. In der Regel handelt es sich um technische Ausnahmen, die in Java als Exceptions auftreten und behandelt werden. Gibt es aber auch fachliche Ausnahmen, also quasi „Domain Exceptions“? Und ist es sinnvoll, diese in Java als Exceptions zu modellieren? Einige Beispiele aus einem Kundenprojekt zeigen, dass dies häufig nicht der Fall ist.

Blog Post

DDD mit Onion Architecture

3 Gründe, weshalb Onion Architecture für die Umsetzung von Bounded Contexts nach Domain-Driven Design besonders geeignet ist.

Blog Post

The language of maths is not the language of your business

Article

Domain- und Test-driven Development mit Spring Boot 2 Softwarearchitektur

Bevor Sie weiterlesen: Für Softwaretests hinsichtlich Anforderungen gilt oftmals das Gleiche wie für Besuche beim Arzt. Eine Diagnose stellt fest, dass es keine Beweise für eine Krankheit gibt. Beweise für die Abwesenheit einer Krankheit gibt es nicht. Sie werden es schwer haben, in einem alltäglichen Projekt, die Abwesenheit von Fehlern hinsichtlich Anforderungen zu beweisen.

Link

Domain-driven Design – Tipps aus der Praxis. Interview mit Michael Plöd

Podcast

Domain-Driven Design

Überblick über Strategic und Technical Design mit DDD

Article

Microservices lieben Domain Driven Design, warum und wie?

Betrachtet man diverse Publikationen rund um Domain Driven Design und Microservices, so stellt man fest, dass das Konzept des Bounded Contexts von zentraler Natur ist. Es gibt kaum eine Veröffentlichung zur Modellierung von Microservices, die dieses Konzept nicht erwähnt. Allerdings greift diese Konstellation zu kurz: es gibt weitaus mehr über Domain Driven Design und Microservices zu berichten als den Bounded Context. Betrachtet man auf der anderen Seite das Thema Domain Driven Design so ist festzustellen, dass das Thema weit über die hinlänglich bekannten Entitäten, Value Objects und Aggregate hinausgeht.

Link

Domain-driven Design im Experten-Check: Wie kann DDD in die Praxis umgesetzt werden?

Link

Domain-driven Design im Experten-Check: Was sind die typischen Probleme bei der Umsetzung von DDD?

Link

Domain-driven Design im Experten-Check: Warum ist DDD heute relevanter denn je?

Article

Domain-Driven Design in Clojure

Obwohl DDD meist im Zusammenhang mit Objektorientierung genannt wird, sind die Prinzipien auch gut mit einer funktionalen Sprache umsetzbar. Eine Einführung in Clojure, dem Lisp für die JVM, bietet beispielsweise [1] [2] [3].

Link

Domain-driven Design in Practice

iSAQB Module DDD

Domain-driven Design in Practice

iSAQB Module DDD

Domain-driven Design in Practice

iSAQB Module DDD

Domain-driven Design in Practice

iSAQB Module DDD

Domain-driven Design umsetzen: Mehr als nur Architektur

IT Tage 2020 / 14:00 - 14:45

Domain-driven Design in Practice

iSAQB Module DDD

ML Use Cases erkennen und ML Anforderungen spezifizieren mit DDD und Design Canvas: Die INNOQ Methode

data2day 2020 / 10:00 - 10:45

Domain-Driven Design to the Code

Command & Control, SAFe, Domain-driven Design, and Release Trains

Handling Complex Software Projects

Identification of quality requirements with Quality Storming

code-your-model

Cloud-native, Microservices, Domain-driven Design, Kubernetes

Alles nur ein Hype?

Event Storming und Domain Story Telling - Ein Vergleich

Cooking with Onions: Inward-Pointing Arrows

Domain Events vs. Event Sourcing

Why domain events and event sourcing should not be mixed up

Domain Events vs. Event Sourcing

Was ist ein Domain-driven Design Architektur-Kata?

Schubladendenken - aber konstruktiv

Verwendung von Stereotypen im Code als Basis für ein gemeinsames Architekturverständnis - und mehr

Domain Exceptions?

DDD mit Onion Architecture

The language of maths is not the language of your business

Domain- und Test-driven Development mit Spring Boot 2 Softwarearchitektur

Domain-driven Design – Tipps aus der Praxis. Interview mit Michael Plöd

Domain-Driven Design

Überblick über Strategic und Technical Design mit DDD

Microservices lieben Domain Driven Design, warum und wie?

Domain-driven Design im Experten-Check: Wie kann DDD in die Praxis umgesetzt werden?

Domain-driven Design im Experten-Check: Was sind die typischen Probleme bei der Umsetzung von DDD?

Domain-driven Design im Experten-Check: Warum ist DDD heute relevanter denn je?

Domain-Driven Design in Clojure

Softwarearchitektur im Großen