Domain-driven Design

11 Feb 2021

GOTOpia Masterclass: Domain-driven Design

GOTOpia February 2021 / 09:00 - 17:00

08 Feb 2021

Domain-Driven Design und Strategic Design: Umsetzung und Praxis-Tipps

OOP 2021 / 18:30 - 20:00

Domain-driven Design und Bounded Context

Die Konzepte von DDD und Bounded Context sind in der Praxis komplizierter, als es auf den ersten Blick erscheint.

Domain-Driven Design to the Code

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.

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

Handling Complex Software Projects

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.

Warum Domain-driven Design?

Domain-driven Design (DDD) ist eine alte Technik, aber gerade voll im Hype. Worum geht es bei DDD und ist der Hype berechtigt?

code-your-model

modularized modeling based on a project-specific DSL

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

Software-Entwicklung unterliegt schon immer Hypes. Im Moment reden alle über Microservices und Cloud-native. Aber helfen diese Ansätze wirklich weiter?

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.

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

Weshalb Domain Events und Event Sourcing nicht vermischt werden sollten

Was ist ein Domain-driven Design Architektur-Kata?

DDD praktisch und konkret vermitteln

Schubladendenken - aber konstruktiv

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

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.

DDD mit Onion Architecture

The language of maths is not the language of your business

Abstractions from category theory can be powerful. But there are reasons why you may want to keep your domain model free of them.

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.

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

Podcast

Domain-Driven Design

Überblick über Strategic und Technical Design mit DDD

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.

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

Gut bewertet