19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Distributed Domain Driven

Design

jeremie chassaing

thinkbeforecoding.com

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Domain Driven Design

• Domain Driven Design offers a lot of

interesting patterns for distribution

• The partitions of your system will emerge

from the Domain model and its Ubiquitous

Language

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Services

• “When a significant process or transformation in

the domain is not a natural responsibility of an

Entity or Value Object, add an operation to the

model as a standalone interface declared as a

Service. Define the interface in terms of the

language of the model and make sure the

operation name is part of the Ubiquitous

Language. Make the Service stateless”

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Services

• Service can be implemented

– As in-process interface implementation

– As an out of process service, the interface can

just be a stub to access the service end point

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Services

• Services should be Stateless

– Real statelessness

– Perceived statelessness (cache, etc)

• Service can be instantiated many times

without conflict

• Clients can switch from one to another

since Services don’t hold state

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Services

• It enables

– Load balancing

– Failover

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Value Objects

• “When you care only about the attributes of an

element of the model, classify it as Value

Object. Make it express the meaning of the

attributes it conveys and give it related

functionality. Treat the Value Object as

immutable.”

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Value Objects

• Value Objects are immutable

• It enables easy use in concurrent code

• They can be shared or duplicated as

needed

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Entities

• “An object defined primarily by its identity is

called an Entity. Entities have special modeling

and design considerations. They have life cycles

that can radically change their form and content,

but a thread of continuity must be maintained.

Their identity must be defined so that they can

be effectively tracked.”

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Entities

• Here, we have problems for distribution:

– Life cycle

– Identity

• Entities are inherently mutable.

• We have to protect against concurrent

changes to make Entities consistent

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Entities

• “It is difficult to guarantee the consistency of

changes to objects in a model with complex

associations. Invariants need to be maintained

that apply to closely related groups of objects,

not just discrete objects. Yet cautious locking

schemes cause multiple users to interfere

pointlessly with each other and make a system

unusable.”

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• “Cluster the Entities and Value Objects into

Aggregates and define boundaries around each.

Choose one Entity to be the root of each Aggregate,

and control all access to the objects inside the boundary

through the root. Allow external objects to hold

references to the root only. […] Because the root

controls access, it cannot be blindsided by changes to

the internals. This arrangement makes it practical to

enforce all invariants for objects in the Aggregate and

for the Aggregate as a whole in any state change.”

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

Car

vehicle id

rotate()

Wheel

local identity

Tire

local id

mileage

Position

time period

mileage

4

4

*

{mileage = sum(Position.mileage)}{time period must not

overlap on same wheel}

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• Aggregates define a boundary

• Inside, consistency is guaranteed

• …

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• Aggregates define a boundary

• Inside, consistency is guaranteed

• Outside, consistency can not be

guaranteed

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• If you need a transaction that spans more

than one aggregate, something is wrong

• Check that you need it to be consistent

• …Or change your boundaries

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• Once Boundaries are well defined, you

can distribute Aggregates

• The identity of an Aggregate is the identity

of its root

• Execute commands on one Aggregate

synchronously

• Execute commands on distinct aggregates

asynchronously

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• Sharding

Aggegates with (Id % 3 == 0)

Aggegates with (Id % 3 == 1)

Aggegates with (Id % 3 == 2)

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• Sharding strategies depend on your

domain

• Some Aggregates that need very high

throughput can be isolated to dedicated

servers

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Aggregates

• Aggregates should be a natural partition

point of your domain

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Bounded Contexts

• “A Bounded Context delimits the applicability of

a particular model so that team members have a

clear and shared understanding of what has to

be consistent and how it relates to other

Contexts. Within that Context, work to keep the

model logically unified, but do not worry about

applicability outside those bounds.”

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Bounded Contexts

• Bounded Contexts also define a boundary

that can be used as a partition point

• Bounded Context can be implemented as

independent services using DDD patterns

for internal distribution

19. und 20. Oktober 2010 in Nürnbergwww.prioconference.de

Conclusion

• Domain Driven Design inherently provide

patterns for distributed architectures

• Partition points should not come from the

implementation details

• Partition points should be found in the

Domain and the Ubiquitous Language