So you want to be a DDD practitioner 

Talysson Oliveira Software architect & Chief Learning Officer at Codeminer42 @talyssonoc talysson.com 

codeminer42.com ai.codeminer42.com @codeminer42 

dddbrasil.com.br linkedin.com/company/dddbrasil youtube.com/@ddd-brasil 

There is a lot of misunderstandings around Domain-Driven Design 

- DDD only adds unnecessary complexity - DDD is a type of software architecture - DDD is a way to organize files and folders - DDD applications have too many files - You have to use a lot of design patterns - DDD makes the code harder to understand - "I never needed DDD for my software to work!" - … 

"All you need to know about DDD" or "DDD lite" tutorials that skip all the important parts 

Forget everything you know about DDD for a second 

Also, stop relating DDD to code 

To practice DDD, you have to know what it's all about 

"The heart of software is its ability to solve domain related problems for the user" Domain-Driven Design - Eric Evans 

Domain - Finance - Health - Education - Shopping - Manufacturing - Mining - Cargo - … Problem "A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain" Model 

Model Car industry Car sales Car Customer Order Payment Customisations Financing terms Colour Extras … 

How are domain models cultivated? 

Domain experts Technical experts (developers, designers, …) 

Domain experts Technical experts (developers, designers, …) 

Domain experts Technical experts (developers, designers, …) Model 

Domain experts Technical experts (developers, designers, …) Ubiquitous language Model 

DDD is a development approach where: - Focus on the core domain - Explore models in creative collaboration - Speak a ubiquitous language 

Are the model and the ubiquitous language universal? No (at least not most of the time) 

Car 

Product 

A model and its ubiquitous language are bounded by a context 

Projects can have multiple models in play at the same time 

Projects can have multiple contexts in play at the same time 

Bounded context A boundary within which a model and a ubiquitous language apply 

No content

Context mapping - Discover the relationships between the contexts - How they share/hide information and influence each other - They place constraints on the nature of the models and pace of change - Contexts that depend on each other mutually (partnership) - Contexts that need to support multiple dependent contexts (open host service) - Contexts that depend unilaterally of some context (conformist) - Contexts that don't even need to know about each other (separate ways) - … - Sometimes you have no control over that relationship! - e.g.: a 3rd party payment processor system 

DDD is not about code 

Source: 

DDD is about communication and knowledge management 

No content

Strategic design 

Strategic design 

Please, do not think DDD is only what we're going to talk from now on ⚠ 

We'll talk about code 

Model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain 

Model-driven design An explanation by example 

id status shippingAddress estimatedDelivery Order 

id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 Order #42 t 

id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 id: 42 status: pending shippingAddress: XYZ Hwy. estimatedDelivery: 10/10/2026 Order #42 t 

id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 id: 42 status: shipped shippingAddress: Av. XYZ estimatedDelivery: 11/11/2026 Order #42 t id: 42 status: pending shippingAddress: XYZ Hwy. estimatedDelivery: 10/10/2026 

id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 id: 42 status: shipped shippingAddress: Av. XYZ estimatedDelivery: 11/11/2026 Order #42 t id: 42 status: pending shippingAddress: XYZ Hwy. estimatedDelivery: 10/10/2026 Identity + life cycle = Entity In your model 

No content

red green blue Colour 

red: 255 green: 0 blue: 0 Red red: 255 green: 0 blue: 255 Pink red: 110 green: 200 blue: 80 Green 

red: 255 green: 0 blue: 0 Red red: 255 green: 0 blue: 255 Pink red: 110 green: 200 blue: 80 Green No conceptual identity + significance comes from describing things = Value object In your model 

No content

id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment 

id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment 

id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment 

id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment OtherObject 

id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment Root entity + conceptual consistency boundary = Aggregate Aggregate root In your model OtherObject 

No content

"Should be an aggregate, an entity or a value object?" 

"Should be an aggregate, an entity or a value object?" It depends 

"Should be an aggregate, an entity or a value object?" on the model It depends — Some DDD practitioner, probably 

find order by id find orders by status persist an order Order (aggregate) 

find order by id find orders by status Persistence actions needed by the domain persist an order Order (aggregate) 

find order by id find orders by status Persistence actions needed by the domain Aggregates that need direct access + set of persistence actions needed by the domain = Repository persist an order Order (aggregate) 

= Repository OrderRepository + findById(id) + findAllByStatus(status) + store(order) Aggregates that need direct access + set of persistence actions needed by the domain 

Domain Infrastructure 

What if a responsibility from the model doesn't naturally fit an entity, aggregate or value object? 

"Sometimes, it just isn't a thing" Domain-Driven Design - Eric Evans 

Order (aggregate) Customer (aggregate) FinancingTerms (value object) Financing a car MonthlyPayment (value object) 

Order (aggregate) Customer (aggregate) FinancingTerms (value object) Financing a car ? MonthlyPayment (value object) 

Order (aggregate) Customer (aggregate) FinancingTerms (value object) Financing a car MonthlyPayment (value object) FinancingQuoteService ⇒ = Domain service Operation that stands alone in the model, without encapsulating state 

Strategic design 

Strategic design Tactical design 

Combine strategic and tactical design! 

Where do we go from here? 

Next steps 1. Run away from the so-called "DDD lite" 2. Start with either: - Domain-Driven Design Distilled (Vaughn Vernon) or Domain-Driven Design Quickly (Abel Avram and Floyd Marinescu) 3. Watch the talk "7 Reasons Why DDD Projects Fail" (Greg Young) 4. Make your fundamentals understanding solid, do not rush it - Domain-Driven Design aka The Blue Book (Eric Evans) or Learning Domain-Driven Design (Vlad Khononov) 5. Practice modeling and coding - Don't use AI for that, frustration is important for learning 6. Go deeper: - Learn EventStorming (Alberto Brandolini) and other techniques for domain discovery and modeling - Read Implementing Domain-Driven Design aka The Red Book (Vaughn Vernon) - Learn event-sourcing (and CQRS) - Read CQRS Documents (Greg Young) - Read Event-Driven (Oskar Dudycz) - Read Architecture for Flow (Susanne Kaiser) 

Go ahead and practice! 

Thank you! @talyssonoc talysson.com @codeminer42 codeminer42.com