Domain Driven Design

more than code

Who am I?

Damiano Petrungaro



Tivoli (RM)

Tivoli (RM)


Tivoli (RM)

Tivoli (RM)

Tivoli (RM)

Me everyday:

What is DDD ?

Domain Driven Design is an approach to software development for complex needs by connecting the implementation to an evolving model.

It is not about code.

It is not, only, about code.

Strategic Design

Tactical Design

The strategic design is the one in which you and the domain experts analyze a domain, define its boundaries, and look for the best way to let communicate different boundaries.

The tactical design describes a group of patterns to use to shape as code the invariants and models defined in a domain analysis that is often (hopefully) driven by the strategic design.

Give a set of tools that you can use to solve common organizational problems.

Goal of this talk:

There will be no code.
At all.

Everything starts with an idea

Let's build a new product!

Let's code it!

Understand the problem


The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.

" The first result of a Google search

Why context matters?



Be naked in:

Nude  Beach

Non-Nude Beach

Context may looks similar but...
Be naked in:

How does it relate to DDD?

Context influences behaviors, the language and the meaning of the words



ubiquitous language

  • Clear communication
    • Teams
    • Customers & CC
    • Onboarding
  • Code express behavior

Bounded Context

It is part of the Strategic Pattern of the DDD literature and it represents a logical boundary where the rules of a sub-domain are applied and make your context unique

Split the problem


Core: is a part of the business that is of primary importance to the success of the organization. 

Supporting: is a part of the business that is essential, but yet not Core.

Generic: is a part of the business that looks like a supporting subdomains but it is not specialized.

A domain visualization

Context map

Bounded contexts are isolated.

But they need to communicate.

9 ways to communicate across contexts

- Partnership

- Shared Kernel

-  Customer-Supplier Development

- Conformist

- Anticorruption layer

- Open Host Service

- Published Language

- Separate ways

- Big ball of mud

Clear dependencies
Clear relationship
Clear contracts


  • Study the problem before solving it
  • Identify sub-domains and scope their contexts
  • Define a common language to use in each sub-domain
  • Find a way to communicate with the other sub-domains defining contracts, if needed

That's it folks!

fun fact: "/giphy damiano"