SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
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.
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).
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.
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
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
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
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
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
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
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!
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