1.
Andre Borgonovo

2.
An approach to the development of complex software
In which we:
1. Focus on the core domain
2. Explore models in a creative collaboration of domain practitioners and software
practitioners
3. Speak a ubiquitous language within an explicitly bounded context

3.
OK, BUT WHY?
IS IT FOR ME?

4.
DOMAIN
“A sphere of knowledge,
influence, or activity. The
subject area to which the user
applies a program is the
domain of the software.”

5.
“Essentially, all models are wrong, but
some are useful.”1
 System of abstractions
 Describe selected aspects of the domain
 Solve problems
1: George E. P. Box, British

6.
“A language structured around
the domain model and used by
all team members within a
bounded context to connect all
the activities of the team with
the software.”

7.
https://martinfowler.com/bliki/BoundedContext.html

8.
MODEL-
DRIVEN
DESIGN

9.
Isolating the domain

10.
Responsible for showing information to the user and
interpreting the user’s commands.
External actor can be
- A human user or;
- Another computer system.

11.
 Application Services (and/or Command Handlers)
 Adapters
 Workflows

12.
The heart of the business software
 Entities
 Aggregates
 Value Objects
 Repository interfaces
 Factories
 Domain Events
 Domain Services

13.
 Data Persistence (Repositories implementation)
 Gateways to external dependencies
 Infrastructure Services
 Crosscutting concerns:
 Logging
 Exception Handling
 Security
 Caching
 ...

14.
User Interface
Application
Domain
Infrastructure
Infrastructure
Persistencedepends on
compose

15.
MODEL
ELEMENTS
Expressing the Model in Software

16.
“An object primarily defined by its
identity”
 Artificial x Natural identity
 Anemic Domain
(aka Reference Objects)
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model

17.
 No identity
 Immutable

18.
 Root Entity (also called Aggregate Root)
 State changes are made via the root Entity, which ensure the Business rules and
keeps the Aggregate valid
 All children have a reference to the root Entity
 Deletion of the aggregate/root, deletes all children;

19.
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model

20.
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model

21.
3 types of services
 Application Services
 Domain Services
 Infrastructure Services
Characteristics of a good Domain Service
 Operation relates to a domain concept that is not a natural part of na Entity or
Value Object
 The interface is defined in terms of other elements of the domain model
 The operation is stateless

22.
FACTORIES
When creation of an entire, internally consistente
aggregate, or a large value object, becomes
complicated or reveals too much of the internal
structure, factories provide encapsulation.

23.
Query access to aggregates expressed
in the ubiquitous language.
 Act in a similar way to a set of
domain objects in memory
 Persistence Ignorance Principle
 One repository per aggregate
 No business rules

24.
 A representation of something that happened in the domain
 Immutable
 Domain Event != System Event

25.
@DDD_Borat

26.
COMMON
PITFALLS
 Relational database mindset masked as
DDD
 Treating DDD as a recipe
 Starting with technical details
 Being superficial about the Domain
 The "One model to rule them all"
approach
 …

27.
DDD IS MORE
THAN THAT!

28.
Intention-
Revealing
Interfaces
Side-Effect-
Free
Functions
Assertions
Standalone
Classes
Closure of
Operations
Declarative
Design
Drawing on
Established
Formalisms
Conceptual
Contours

29.
Context Map Partnership
Shared
Kernel
Customer/
Supplier
Development
Conformist
Anticorruptio
n Layer
Open-host
Service
Published
Language
Separate
Ways
Big Ball of
Mud

30.
DISTILLATI
ON FOR
STRATEGIC
DESIGN
Core Domain
Generic Subdomains
Domain Vision Statement
Highlighted Core
Cohesive Mechanisms
Segregated Core
Abstract Core

31.
EVOLVING
ORDER
SYSTEM
METAPHOR
RESPONSABILIT
Y LAYERS
KNOWLEDGE
LEVEL
PLUGGABLE
COMPONENT
FRAMEWORK

32.
https://devblogs.microsoft.com/cesardelatorre/domain-driven-design-ddd-visual-studio-11-beta-alm-great-fit/

33.
MORE
 http://domainlanguage.com/
 https://docs.microsoft.com/en-
us/dotnet/standard/microservices-
architecture/microservice-ddd-cqrs-patterns/
 https://github.com/VaughnVernon/IDDD_Samples
 https://aspnetboilerplate.com/
 https://github.com/vlingo

34.
ANDRE BORGONOVO
Software Consultant at WAES
Design Engineer at ASML
MCSD, PSM, ITIL
linkedin.com/in/azborgonovo
@azborgonovo
Software Developer | Leader | Architect