Intro to DDD by Tin Anh Nguyen

Table of Contents

  • What
  • Why
  • How

What is DDD?

Domain-Driven Design

Domain-Driven Design

  • Coined by Eric Evans
  • Presented in "The Blue Book"
  • Published in 2003
Domain-Driven Design by Eric Evans

Boils down to a single idea

The implementation model should reflect the domain model

Why do DDD?

Ubiquitous Language

  • Shared language
  • Communicate with experts
  • Less misunderstandings

Ubiquitous Language

Conversations with and without DDD

Knowledge Sharing

  • Model captures insights
  • Learn domain more quickly
  • Shorten on-boarding time

Clarity

  • Discover new opportunities
  • React to changes more easily
    • Alignment with business

Productivity Over Time

Graph showing productivity with and without DDD

How to do DDD?

Continuous Refactoring

  • Talk to domain expert
  • Crunch knowledge
  • Refine model
  • Discover issues
  • Repeat the process

Continuous Refactoring

Continuous refinement of ubiquitious language

Continuous Refactoring

Perfect design versus over- and underdesign

Continuous Refactoring

Example of a simplified but effective model

Knowledge Crunching Techniques

Domain Storytelling example Event Storming example

Modeling techniques

  • Tactical Design
  • Strategic Design
Overview of concepts in tactical design Example on different bounded contexts

That's How

But...

Supporting Foundation

  • Object-Oriented Programming
  • Hexagonal Architecture
  • Event-Driven Architecture

When to do DDD?

Always

Unless you're creating a throwaway application

Team Might Not Do DDD

Doesn't mean that you can't

Thank you for listening

Join us at #learn-ddd to learn more!

Credits