Domain-driven design is a collaborative process involving both domain experts and software practitioners that attempts to address issues of complexity in software. This process is described in the book Domain-Driven Design written by Eric Evans. Domain-driven design starts with the assertion that complexity is in the domain, not in the technology. Accordingly, we must let technology play a supporting role. A person practicing domain-driven design does not attempt to model reality. Instead, domain experts and software practitioners use a mental model as a tool for solving problems within a given domain. The domain experts and software practitioners collaborate to explore and develop this model. We will look at the concept of a bounded context within which models can be isolated and explored. We will talk about domain-driven design's building block patterns including entities, value objects, aggregates, repositories, services, and domain events. We will see how test-driven development can be used as a means of exploring the model.

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

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

3. Training
http://www.domainlanguage.com/

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

5. Complexity is in the domain,
not the technology

6. Case Study: Election Reporting

7. Elections vs. Referendums
Elections and referendums are not as similar as
they at first appear
Election winners may be determined by plurality
and/or winning threshold
Referendums can only be passed by meeting a
winning threshold

8. Local vs. Statewide Elections
Town Meeting Day (March) elections are very different than
statewide elections (November)
During statewide elections, voters may be voting in both local and
statewide elections at the same time—each with different district
boundaries
District boundaries dictate reporting needs—statewide elections
need to be reported one way, local elections another

9. Districts
Some districts may contain only part of a municipality or ward
The Chittenden-3-6 Vermont Representative District contains all
of Winooski and part of Burlington’s Ward 1
Citizens in this part of Burlington’s Ward 1 vote in Winooski for
statewide elections and in Burlington for local elections
Audience expects both aggregate and detailed reporting
Redistricting can occur between elections

10. Let technology play
a supporting role

11. Models are tools used to
solve domain problems

12. Ames Room
Used in The Lord Of The
Rings: The Fellowship of
the Ring to make the
hobbits appear the
correct size in relation
to Gandalf
We are always using
mental models to
understand the world
around us—we do not
perceive an objective
reality
By Alex Valavanis (own work) [public domain], via Wikimedia Commons

13. "Why I prefer Fahrenheit to Celsius [Fixed]." reddit. 2012.
http://www.reddit.com/r/funny/comments/wigk1/why_i_prefer_fahrenheit_to_celsius_fixed/ (16 September 2012).

14. Collaboratively explore the model
with both domain experts and
software practitioners

15. Case Study:
Three-Dimensional Animation

16. Software Practioner:
Edwin Catmull
Studied physics and computer science
Made many notable computer graphics discoveries
Eventually moved from two-dimensional to
three-dimensional animation
Hired by Lucasfilm to bring his expertise to the
entertainment field

17. Domain Expert:
John Lasseter
Studied animation and taught by veteran animators from Disney
Realized early-on the potential for computer generated imagery
Worked at, but eventually fired from, Disney
Hired by Edwin Catmull at Lucasfilm as an “Interface Designer”
because Catmull’s job didn’t include hiring animators[1]
1. Buckley, A. M. "Chapter 3: Art Meets Science." Pixar: The Company and Its Founders. Edina, MN: ABDO, 2011. 27. Print.

18. “Throughout the process, Lasseter
worked side-by-side with the computer
scientists. Lasseter’s requests pushed
them to develop new tools, and their
feedback helped him learn the digital
animation process.”[1]
1. Buckley, A. M. "Chapter 3: Art Meets Science." Pixar: The Company and Its Founders. Edina, MN: ABDO, 2011. 30. Print.

19. Identify your core domain

20. Core Domain
Identify your core domain
Distill your core domain
Focus your resources on the core domain

21. Collaboratively explore
domain models

22. The Model
A model is an abstract set of tools that is used to
solve problems within a domain
While represented in code, do not think of the
model as just code
A “real world model” is a fool’s errand
The model must be explored collaboratively with
domain experts and software practitioners

23. “The map is not the territory.”
—Alfred Korzybski

24. Magritte, René. The Treachery of Images (La trahision des images). 1929. Oil on canvas. Los Angeles County Museum of Art, Los Angeles, California.

25. This is not a pipe.
Magritte, René. The Treachery of Images (La trahision des images). 1929. Oil on canvas. Los Angeles County Museum of Art, Los Angeles, California.

27. "Everything simple is false. Everything
which is complex is unusable."
—Paul Valéry

28. There are always multiple models

29. Bounded Context
Delineates the applicability of a particular model
Bounded contexts allow each model to be explored in isolation
Clearly define:
• Who is responsible for each bounded context
• To which parts of the application is the bounded
context applicable
• What manifestations the bounded context will take
(code, database schemas, etc.)
Document the interactions between bounded contexts
with a context map

30. Ubiquitous Language
Speak a ubiquitous language within a bounded context
Terms must be clearly defined, unambiguous, and consistent
Critically important when communicating between
domain experts and software practitioners
The ubiquitous language will (and must) evolve as a progressively
richer understanding of the domain and the model are achieved
If the ubiquitous language cannot be used to clearly express
complex ideas, then you have more work to do!

31. Exploring the Model

32. A Model Exploration Process
Ask a domain expert to tell you a story (the scenario)
Propose a model
Code the scenario using unit tests
Repeat

34. Use concrete scenarios in discussions
with domain experts and in unit tests

35. Building Blocks

36. Entity
Defined 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

37. Value Object
Defined by its encapsulated attributes
Treat value objects as immutable
Delegate business logic to value objects

38. Defining an object as an entity or a
value object is context-dependent

39. Aggregate
A group of related entities and value objects
Useful when defining transaction, distribution
and concurrency boundaries
A model will likely have multiple aggregates

40. Aggregate Root
Designate one entity as the aggregate root
Allow external references to only the aggregate root
Use unidirectional references within an aggregate root
for less complexity
• Example: Reference a line item’s order, or an order’s line items,
but not both
Maintain references on the “many” side of a “one-to-many”
relationships for less complexity:
• Example: Reference a line item’s order, rather than an order’s
line items

41. Repository
Delegate persistence of an aggregate root to a repository
A repository should behave as if it were an in-memory data store
If using an object-relational mapper (ORM):
Database -> ORM -> Repository
Use an in-memory strategy for unit tests
Straddles persistence and domain layers, allowing you to
stay focused on the domain model

42. Service
A place for operations that aren’t naturally part of
any domain object
Like value objects, services should be immutable
Operations on services are stateless

43. Command-Query Responsibility
Segregation (CQRS)

44. Commands & Queries
Commands are responsible for changing state
Queries are responsible for retrieving state
A commands may delegate the actual state change
to a domain event

45. Write Model/Read Model
Define one model for writing data (commands)
Define another model for reading data (queries)
Both models will likely share aggregate root entity identifiers

46. Event Sourcing[1]
1. http://martinfowler.com/eaaDev/EventSourcing.html

47. Domain Event
Something important that happens within the domain
that may lead to a state change in a domain object
Domain events can trigger other domain events (e.g.
three strikes triggers an out)
Domain events are immutable
Typically stored in an event log

48. Event Log
Current state can be computed by reading the event log
Retroactive events can be used to “fix” application state
Current state may be cached, if necessary for performance
Can also serve as an audit log

49. Supple Design

50. 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 integer
• integer has an add method
• add method accepts an argument of type integer
• add method returns an integer
• integers are closed under the operation of addition

51. Other Techniques
Intention-revealing interfaces
Side-effect free functions
Assertions

52. Strategic Design

53. Context Map
Draw a context map of the current bounded contexts
Map what actually exists—not what you wish existed!
Identify relationships between contexts

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

55. Distillation

56. Types of Domains
A model my represent:
• your core domain
• a supporting domain
• a generic subdomain
Focus your modeling efforts on the core domain
Consider outsourcing work on supporting domains
Consider off-the-shelf software for generic subdomains

57. 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?

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

59. http://oreilly.com/catalog/9781449303129/ http://oreilly.com/catalog/9781449303433/

60. Thank You
@BradleyHolt
http://bradley-holt.com
Copyright © 2011-2012 Bradley Holt. All rights reserved.