Domain-driven design is a collaborative process involving both domain experts and software practitioners. This high-level overview takes a look at the driving principles behind domain-driven design. It also explores domain-driven design's building block patterns, supple design, strategic design, and distillation of the core.
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).
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.
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
20. Entity
• de ned by a thread of continuity and identity
• only responsibilities should be around identity and life cycle
21. 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
29. Aggregate
• a group of related entities and value objects
• useful when de ning transaction, distribution and
concurrency boundaries
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
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
32. 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
34. 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
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])
1. http://martinfowler.com/eaaDev/EventSourcing.html
36. 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
39. Closure of Operations
• have a method on a value object that returns an instance
of the same type of 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
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
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
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
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
45. 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
50. Context Map
• draw a context map of the current bounded contexts
• map what actually exists—not what you wish existed!
51. Context Map
• draw a context map of the current bounded contexts
• map what actually exists—not what you wish existed!
• identify relationships between contexts
52. Relationship Patterns
customer/ anticorruption
partnership supplier layer
shared kernel big ball of separate ways
mud
open host conformist published
service language
57. Multiple Models
• there are always multiple models
• a model my represent:
• your core domain
58. Multiple Models
• there are always multiple models
• a model my represent:
• your core domain
• a supporting domain
59. Multiple Models
• there are always multiple models
• a model my represent:
• your core domain
• a supporting domain
• a generic subdomain
60. 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
61. 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?
Is a telephone number an entity or a value object? In a CRM, it’s probably a value object. In a telephone company, a phone number may be an entity.\n