Domain-Driven Design

60
Domain-Driven Design A Collaboration Between Domain Experts and Software Practitioners

description

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.

Transcript of Domain-Driven Design

Page 1: Domain-Driven Design

Domain-Driven DesignA Collaboration Between

Domain Experts and Software Practitioners

Page 4: Domain-Driven Design

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).

Page 5: Domain-Driven Design

Complexity is in the domain, not the technology

Page 6: Domain-Driven Design

Case Study: Election Reporting

Page 7: Domain-Driven Design

Elections and referendums are not as similar as they at $rst appear

Election winners may be determined by plurality and/or winning threshold

Referendums can only be passed by meeting a winning threshold

Elections vs. Referendums

Page 8: Domain-Driven Design

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

Local vs. Statewide Elections

Page 9: Domain-Driven Design

DistrictsSome 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

Page 10: Domain-Driven Design

Let technology play a supporting role

Page 11: Domain-Driven Design

Models are tools used to solve domain problems

Page 12: Domain-Driven Design

Ames RoomUsed 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

Page 13: Domain-Driven Design

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

Page 14: Domain-Driven Design

Collaboratively explore the model with both domain experts and software practitioners

Page 15: Domain-Driven Design

Case Study: Three-Dimensional Animation

Page 16: Domain-Driven Design

Studied physics and computer science

Made many notable computer graphics discoveries

Eventually moved from two-dimensional to three-dimensional animation

Hired by Lucas$lm to bring his expertise to the entertainment $eld

Software Practioner: Edwin Catmull

Page 17: Domain-Driven Design

Domain Expert: John LasseterStudied animation and taught by veteran animators from Disney

Realized early-on the potential for computer generated imagery

Worked at, but eventually $red from, Disney

Hired by Edwin Catmull at Lucas$lm 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.

Page 18: Domain-Driven Design

“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.

Page 19: Domain-Driven Design

Identify your core domain

Page 20: Domain-Driven Design

Identify your core domain

Distill your core domain

Focus your resources on the core domain

Core Domain

Page 21: Domain-Driven Design

Collaboratively explore domain models

Page 22: Domain-Driven Design

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

The Model

Page 23: Domain-Driven Design

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

Page 24: Domain-Driven Design

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

Page 25: Domain-Driven Design

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.

Page 26: Domain-Driven Design
Page 27: Domain-Driven Design

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

Page 28: Domain-Driven Design

There are always multiple models

Page 29: Domain-Driven Design

Delineates the applicability of a particular model

Bounded contexts allow each model to be explored in isolation

Clearly de$ne:• 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

Bounded Context

Page 30: Domain-Driven Design

Ubiquitous LanguageSpeak a ubiquitous language within a bounded context

Terms must be clearly de$ned, 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!

Page 31: Domain-Driven Design

Exploring the Model

Page 32: Domain-Driven Design

Ask a domain expert to tell you a story (the scenario)

Propose a model

Code the scenario using unit tests

Repeat

A Model Exploration Process

Page 34: Domain-Driven Design

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

Page 35: Domain-Driven Design

Building Blocks

Page 36: Domain-Driven Design

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

Entity

Page 37: Domain-Driven Design

Value ObjectDe$ned by its encapsulated attributes

Treat value objects as immutable

Delegate business logic to value objects

Page 38: Domain-Driven Design

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

Page 39: Domain-Driven Design

A group of related entities and value objects

Useful when de$ning transaction, distribution and concurrency boundaries

A model will likely have multiple aggregates

Aggregate

Page 40: Domain-Driven Design

Aggregate RootDesignate 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

Page 41: Domain-Driven Design

RepositoryDelegate 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

Page 42: Domain-Driven Design

ServiceA place for operations that aren’t naturally part of any domain object

Like value objects, services should be immutable

Operations on services are stateless

Page 43: Domain-Driven Design

Command-Query Responsibility Segregation (CQRS)

Page 44: Domain-Driven Design

Commands are responsible for changing state

Queries are responsible for retrieving state

A commands may delegate the actual state change to a domain event

Commands & Queries

Page 45: Domain-Driven Design

Write Model/Read ModelDe$ne one model for writing data (commands)

De$ne another model for reading data (queries)

Both models will likely share aggregate root entity identi$ers

Page 46: Domain-Driven Design

Event Sourcing[1]

1. http://martinfowler.com/eaaDev/EventSourcing.html

Page 47: Domain-Driven Design

Domain EventSomething 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

Page 48: Domain-Driven Design

Event LogCurrent state can be computed by reading the event log

Retroactive events can be used to “$x” application state

Current state may be cached, if necessary for performance

Can also serve as an audit log

Page 49: Domain-Driven Design

Supple Design

Page 50: Domain-Driven Design

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

Closure of Operations

Page 51: Domain-Driven Design

Other TechniquesIntention-revealing interfaces

Side-effect free functions

Assertions

Page 52: Domain-Driven Design

Strategic Design

Page 53: Domain-Driven Design

Draw a context map of the current bounded contexts

Map what actually exists—not what you wish existed!

Identify relationships between contexts

Context Map

Page 54: Domain-Driven Design

customer/supplier

Relationship Patterns

partnership

shared kernelbig ball of

mud

conformist

anticorruption layer

separate ways

open host service

published language

Page 55: Domain-Driven Design

Distillation

Page 56: Domain-Driven Design

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

Types of Domains

Page 57: Domain-Driven Design

Identifying the Core DomainAsk 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?

Page 58: Domain-Driven Design

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

Page 60: Domain-Driven Design

Thank You@BradleyHolt

http://bradley-holt.com

Copyright © 2011-2012 Bradley Holt. All rights reserved.