1.
Domain-Driven Design
A Collaboration Between
Domain Experts and Software Practitioners

2.
The Book
http://domaindrivendesign.org/books/evans_2003

3.
do·main
dōˈmān n.
a sphere of knowledge,
in uence, or activity
"domain." Merriam-Webster.com. 2011. http://www.merriam-webster.com/dictionary/domain (17 October 2011).

4.
Core Domain

5.
Core Domain
• complexity is in the domain, not the technology

6.
Core Domain
• complexity is in the domain, not the technology
• let technology play a supporting role

7.
Core Domain
• complexity is in the domain, not the technology
• let technology play a supporting role
• uncover your core domain and distill this core

8.
The Model*
*In domain-driven design, the model is not the classes or objects representing concepts within the model.

9.
The Model*
• a model is a tool for solving speci c problems within a domain
*In domain-driven design, the model is not the classes or objects representing concepts within the model.

10.
The Model*
• a model is a tool for solving speci c problems within a domain
• “the map is not the territory” —Alfred Korzybski
*In domain-driven design, the model is not the classes or objects representing concepts within the model.

11.
The Model*
• a model is a tool for solving speci c problems within a domain
• “the map is not the territory” —Alfred Korzybski
• collaborative explore the model with both domain experts
and software practitioners
*In domain-driven design, the model is not the classes or objects representing concepts within the model.

12.
Bounded Context

13.
Bounded Context
• there are always multiple models

14.
Bounded Context
• there are always multiple models
• explicitly de ne a bounded context to which a model applies

15.
Bounded Context
• there are always multiple models
• explicitly de ne a bounded context to which a model applies
• speak a ubiquitous language within a bounded context

16.
Building Blocks

17.
Entity

18.
Entity
• de ned by a thread of continuity and identity

19.
Entity
• de ned by a thread of continuity and identity
• only responsibilities should be around identity and life cycle

20.
Entity
• de ned by a thread of continuity and identity
• only responsibilities should be around identity and life cycle
• may be composed of other entities and/or value objects

21.
Value Object

22.
Value Object
• de ned by its encapsulated attributes

23.
Value Object
• de ned by its encapsulated attributes
• treat value objects as immutable

24.
Value Object
• de ned by its encapsulated attributes
• treat value objects as immutable
• delegate business logic to value objects

25.
De ning an object as an entity or a
value object is context-dependent.

26.
Aggregate

27.
Aggregate
• a group of related entities and value objects

28.
Aggregate
• a group of related entities and value objects
• useful when de ning transaction, distribution and
concurrency boundaries

29.
Aggregate
• a group of related entities and value objects
• useful when de ning transaction, distribution and
concurrency boundaries
• designate one entity as the aggregate root

30.
Aggregate
• a group of related entities and value objects
• useful when de ning transaction, distribution and
concurrency boundaries
• designate one entity as the aggregate root
• allow external references to only the aggregate root

31.
Aggregate
• a group of related entities and value objects
• useful when de ning transaction, distribution and
concurrency boundaries
• designate one entity as the aggregate root
• allow external references to only the aggregate root
• delegate persistence of an aggregate root to a repository

32.
Domain Event
1. http://martinfowler.com/eaaDev/EventSourcing.html

33.
Domain Event
• something important that happens within the domain that
may lead to a state change in a domain object
1. http://martinfowler.com/eaaDev/EventSourcing.html

34.
Domain Event
• something important that happens within the domain that
may lead to a state change in a domain object
• current state can be computed by looking at all currently
known domain events (a.k.a. event sourcing[1])
1. http://martinfowler.com/eaaDev/EventSourcing.html

35.
Domain Event
• something important that happens within the domain that
may lead to a state change in a domain object
• current state can be computed by looking at all currently
known domain events (a.k.a. event sourcing[1])
• domain events can trigger other domain events (e.g. three
strikes triggers an out)
1. http://martinfowler.com/eaaDev/EventSourcing.html

36.
Supple Design

37.
Closure of Operations

38.
Closure of Operations
• have a method on a value object that returns an instance
of the same type of value object

39.
Closure of Operations
• have a method on a value object that returns an instance
of the same type of value object
• any method arguments should also be the same type as
the value object

40.
Closure of Operations
• have a method on a value object that returns an instance
of the same type of value object
• any method arguments should also be the same type as
the value object
• example: 2 + 3 = 5

41.
Closure of Operations
• have a method on a value object that returns an instance
of the same type of value object
• any method arguments should also be the same type as
the value object
• example: 2 + 3 = 5
• “2” is a value object of type number

42.
Closure of Operations
• have a method on a value object that returns an instance
of the same type of value object
• any method arguments should also be the same type as
the value object
• example: 2 + 3 = 5
• “2” is a value object of type number
• number has an add method

43.
Closure of Operations
• have a method on a value object that returns an instance
of the same type of value object
• any method arguments should also be the same type as
the value object
• example: 2 + 3 = 5
• “2” is a value object of type number
• number has an add method
• add method accepts an argument of type number

44.
Closure of Operations
• have a method on a value object that returns an instance
of the same type of value object
• any method arguments should also be the same type as
the value object
• example: 2 + 3 = 5
• “2” is a value object of type number
• number has an add method
• add method accepts an argument of type number
• add method returns a number

45.
Other Techniques
• intention-revealing interfaces
• side-effect free functions
• assertions

46.
Strategic Design

47.
Context Map

48.
Context Map
• draw a context map of the current bounded contexts

49.
Context Map
• draw a context map of the current bounded contexts
• map what actually exists—not what you wish existed!

50.
Context Map
• draw a context map of the current bounded contexts
• map what actually exists—not what you wish existed!
• identify relationships between contexts

51.
Relationship Patterns
customer/ anticorruption
partnership supplier layer
shared kernel big ball of separate ways
mud
open host conformist published
service language

52.
Distillation

53.
Multiple Models

54.
Multiple Models
• there are always multiple models

55.
Multiple Models
• there are always multiple models
• a model my represent:

56.
Multiple Models
• there are always multiple models
• a model my represent:
• your core domain

57.
Multiple Models
• there are always multiple models
• a model my represent:
• your core domain
• a supporting domain

58.
Multiple Models
• there are always multiple models
• a model my represent:
• your core domain
• a supporting domain
• a generic subdomain

59.
Multiple Models
• there are always multiple models
• a model my represent:
• your core domain
• a supporting domain
• a generic subdomain
• focus your modeling efforts on the core domain

60.
Identifying the Core Domain
Ask organizational leaders and domain experts:
• What keeps you awake at night?
• What makes your system worth writing?
• Why not buy it off the shelf?
• Why not outsource it?

61.
Don’t settle on not having
access to a domain expert!

62.
Thank You
@BradleyHolt
http://bradley-holt.com
http://joind.in/4003
Copyright © 2011 Bradley Holt. All rights reserved.