How does Domain-Driven Design work?

Tomaš Maconkotomasmaconko@gmail.com

What is it?“That’s just a rubbish theory!”“Its just another way to structure your code!”“Its hard to understand!”“It requires lots of useless coding!”“Nobody wants to use it!”

What is it?“Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.”

What is complexity?•Business is the domain•Complexity is the domain (problem) itself•Domain consists of complex processes, workflows, rules etc. •Different specialists collaborate together to make business value

CAR BUSINESS DOMAIN

Domain areas

Core subdomain

Supporting subdomains

Core subdomain and supporting subdomains•DDD requires you to examine the business deeply• It enables you to split up the problem into smaller pieces (subdomains) to outline the core piece (core subdomain)•Allows you to pay attention to each piece separately (even to work in different teams) and concentrate mostly on the core

Core subdomain

Lets look inside• Marketing• Sales• Billing• Production• Logistics• Operations• …

BOUNDED CONTEXTS

Bounded context•A pattern in Domain-Driven Design•A chunk of solution space•Helps dealing with large models•Ubiquitous language

Ubiquitous language

Ubiquitous language•Requires people in same bounded context using same terms (dictionary)•Same term is unambiguous for all team members (domain experts, developers, QA, etc.)•Defined and maintainable by whole team

Car (production): engine, wheels,

body, …

Car (billing): car parts expenses,

salaries

Car (marketing): photo, video, description, …

PRODUCTION

Value object•Does not have identity•Comparable by all its attributes•IMMUTABLE!•Allows to encapsulate business rules

Value object

Entity•A set of attributes and verbs•Has identity (engine ID number)•Cannot (logically) work without aggregate•Mutable

Entity

Aggregate and aggregate root•Entity• Joins related entities and value objects•Encapsulates complex and state-dependent requirements in domain classes• It is highly recommended (required) to have single aggregate per transaction

Aggregate

Aggregate root

Respository• Encapsulates aggregates persistence and retrieval• Persistence ignorance• Can be used as abstraction for different underlying

technologies (SQL, NoSQL, web-services, caching, etc.)• One repository per aggregate

Repository

INTEGRATION

How to combine stuff together?2. Stop pedal

pressed!

1. I listen for stop pedal

pressed

1. I listen for stop pedal

pressed3. I handle it

3. I handle it

4. Started

stopping

4. Stop lights turned

on

1. I listen for

acceleration pedal

pressed

Domain event•Messages in past tense•Result of completed command• Integrates aggregates or bounded contexts with minimal coupling and dependencies•Reduces the number of changes in existing code• Improves responsiveness (asynchronous processing)

THAT’S IT!

Pros• Involves team into domain analysis•Helps splitting and understanding the domain•Unambiguous terms• Changes the way developers think about solution• Strong domain model• Clean and maintainable code

DDD

Domain

Cons•Requires team time and effort for analysis•Requires stronger skills on modeler side and OOP•Complicates small systems•Requires time to define UL DDD

So, what next?• CQRS• Event sourcing• Microservices