Reactive Domain Driven Design - elsassjug

Reactive
Domain Driven Design
• EBIA ALLIANCE = XEBIA + XEBIALABS + THIGA + UX REPUBLIC

The Objective

The red squadron

Characters
/Alliance /Red squadron
/Empire / DeathStar

Attack class Alliance{
val squadrons = Set[Squadron];
!
def attack(empire){
!
val deathStar = empire.deathStar
!
squadron.foreach(squadron =>
squadron.attack(deathStar)
)
}
}

Idle

class Squadron{
var location = base;
!
def attack(){
travelTo(deathStar){
…
this.location = deathStar
…
}
!
}
}
Traveling

class Squadron{
val xwings = Set[Squadron];
!
def attack(deathStar){
travelTo(deathStar)
!
do{
xwings.foreach(_.attack(deathStar))
}while(deathStar.alive)
!
}
}
Fighting

class XWing{
var healthPoints = 1
!
!
deathStar.receiveTorpedoFrom(this)
!
!
!
!
}
}
Fighting

class DeathStar{
!
def receiveTorpedoFrom(sender){
healthPoints -= 1
if(senderWithoutTheForce){
sender.receiveTorpedoFrom(this)
}
}
!
}
Fighting

User Story
As the Alliance
!
I want to be informed of updates in state of my
squadrons
!
In order to command the retreat
of a squadron if it remains only one XWing

Tasks
Notification from XWing
to Squadron Notification from
Squadron to Alliance
Implements
Squadron#retreat

to Squadron
class XWing{
!!!
!
println(s”$this is dead”)
}
}

class XWing{
!
val squadron = parent
!
squadron.remove(this)
}
}
to Squadron

} Remember
No bidirectional
references
class XWing{
!
!
}
to Squadron

to Squadron
} What would be
class XWing{
!
!
}
visibility of
remove?

class XWing{
!
!
}
!
}
to Squadron

class XWing{
!
val life = Promise[Unit]()
!
life.success(null)
}
!
def endOfLife = life.future
}
to Squadron

to Squadron
class XWing{
!
!
life.success(null)
}
!
}
class Squadron{
var xwings = Set[XWing]()
!
xwings.foreach(xwing =>
xwing.endOfLife.map(_ =>
xwings -= xwing
)
)
!
}

to Squadron
class XWing{
!
!
life.success(null)
}
!
}
class Squadron{
!
xwings -= xwing
)
)
!
} Loosely coupled

to Squadron
But we starts with
asynchronous
class XWing{
!
!
life.success(null)
}
!
}
class Squadron{
!
xwings -= deadXWing
)
)
!
} Loosely coupled

Notification from
class Alliance{
val squadrons = Seq[Squadron]()
!
!!!!!!!
}
class Squadron{
!
xwings -= deadXWing
)
)
!
def alliance = ???
}

Notification from
class Alliance{
!
!!!!!!!
}
class Squadron{
!
xwings -= deadXWing
)
)
!
def alliance = ???
} Remember again
No bidirectional
references

Notification from
class Alliance{
!
!!!!!!!
}
class Squadron{
!
xwings -= deadXWing
)
)
!!
}

Notification from
class Alliance{
squadrons.foreach(squadron =>
squadron.listener += {
updatedSquadron => {
if(updatedSquadron.currentSize < 2){
updatedSquadron.retreat()
}
}
}
)
!!!!
}
class Squadron{
!
xwings -= deadXWing
listeners.foreach(l =>
l.apply(this)
)
)
)
var listeners = List[Squadron => Unit]
!
def currentSize = xwings.size
!
def retreat = ???
}

Notification from
class Alliance{
squadrons.foreach(squadron =>
squadron.listener += {
updatedSquadron => {
if(updatedSquadron.currentSize < 2){
updatedSquadron.retreat()
}
}
}
)
!!!!
}
class Squadron{
!
xwings -= deadXWing
listeners.foreach(l =>
l.apply(this)
)
)
)
var listeners = List[Squadron => Unit]
!
def currentSize = xwings.size
!
def retreat = ???
}
Will make
the tests
green

Tasks
Notification from
Implements
Squadron#retreat

class Squadron{
!
def retreat() = ???
!!!!!!
}
Implements
Squadron#retreat

class Squadron{
!
def retreat() = {
travelTo(base)
}
!!!!!
}
Implements
Squadron#retreat

class Squadron{
def retreat() = {
travelTo(base)
}
!!!!!
}
Implements
Squadron#retreat
That does not
stop XWings to
fire

class Squadron{
var fighting = false
def retreat() = {
figthing = false
travelTo(base)
}
!
travel(deathStar)
fighting = true
do {
} while (deathStar.alive && fighting)
}
}
Implements
Squadron#retreat
Will make
the tests
green

class Squadron{
var fighting = false
def retreat() = {
figthing = false
travelTo(base)
}
!
travel(deathStar)
fighting = true
do {
} while (deathStar.alive && fighting)
}
}
Implements
Squadron#retreat
But wait
we have
a shared
mutable state

User Story
As the Alliance
!
I want to display each modification in the status
of my squadron
!
In order to see evolution of the battle

Tasks
Get current status
as String
from a Squadron
Notification at the end
of travels

class Squadron{
!
xwing.endOfLife.map { _ =>
!!
}
)
!!!!!
}
of travels

class Squadron{
!
xwing.endOfLife.map { _ =>
notifyListeners()
!
}
)
!
def attack(deathStar: DeathStar){
!
travelTo(deathStar)
notifyListeners()
!
}
!
def retreat(){
travelTo(base)
notifyListeners()
}
}
of travels
Will make
the tests
green

class Squadron{
!!
!!!!!
}
Get current status
as String
from a Squadron

class Squadron{
!
status(“idle“)
status(“traveling“)
notifyListeners()
!
travelTo(deathStar)
status(“figthing“)
notifyListeners()
}
!
…
!!
}
Get current status
as String
from a Squadron
That’s too
much,
there must be
another way

Backlog
Make the travel asynchronous
so many squadrons can move
at the same time
Persist state of squadrons
to spawn them on new VM
if lost

Domain Driven Design

http://www.amazon.fr/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

Technical core concepts
Aggregate
Bounded context

Technical core concepts scalability
code
Aggregate
Bounded context
transaction

code
scalability

code
scalability
Knight
Knight

code
scalability
Implementation
is focused on a
bounded context of
the whole domain
Knight
Knight

code
scalability
Aggregate hides
implementation
details

code
scalability
Aggregate hides
implementation
details
Implementation
is focused on a
bounded context of
the whole domain

transaction

transaction
?

transaction
Root entity
ensures
consistency of
the whole
aggregate at
any time

transaction
!
can see
4 XWings

transaction
When the Alliance
can see the changes?
!
can see
3 XWings

transaction
!
can see
3 XWings
From an external
point of view, the
aggregate is
eventually
consistent!

transaction
From an external
point of view, the
aggregate is
eventually
consistent!
Root entity
ensures
consistency of
the whole
aggregate at
any time

CQRS
Domain Driven Design ++
EventSourcing

CQRS
Command Query Responsibility Segregation
Forget about
POJOs and Java Beans
getters/setters.
Do semantical methods!
You can model your
domain twice! Once
per usage.
!
Command ≠ Query

EventSourcing
Forget about Hibernate
and other ORMs.
Persists meaningful
past events.
!
Command ≠ Event

Functional
EventSourcing
x (Aggregate) (Actions) Events Decision
Command State
making
Events x State
(Aggregate)
apply State
(Aggregate)
+

Functional
EventSourcing
You don’t even
need to persist
complete aggregates
x (Aggregate) (Actions) Events Decision
Command State
making
Events x State
(Aggregate)
state !
apply State
(Aggregate)
+

Functional
EventSourcing
x (Aggregate) Events Decision
Command State
making
Events x State
(Aggregate)
apply State
(Aggregate)

Functional
EventSourcing
source: @thinkbeforecoding
x (Aggregate) Events Decision
Command State
making
https://github.com/thinkbeforecoding/FsUno.Prod
Events x State
(Aggregate)
!
apply State
(Aggregate)

Command ≠ Query Command ≠ Event

Event Actions
Command

Event Actions
But where are
the views?
Command

And the views?
You can keep
specific views
inside aggregates.
You’ll bother
the root for
minor subjects. Lost(red-1)
Reporter

And the views?
You read events log
and build
ad-hoc views.
!
In « real-time »
or on demand.
Listener
Lost(red-1)

In DDD, aggregates and
entities have unique
IDs.
So does the actors
with paths and name
In DDD, value object
are everywhere and
are immutable.
So does case classes.
Immutability
help reasoning
in concurrent
world.
In DDD, aggregates
encapsulate states,
so does actors

Reactive

http://www.reactivemanifesto.org/

asynchronous
low coupling

scaling to
workload

sane
error and failure
handling

system always responds
in bounded latency

Tasks
Let’s do a refactor
with Akka

Aggregate
Red squadron

Actors
/Alliance /Red squadron
/Empire / DeathStar

Functional
EventSourcing
x (Aggregate) Actions Events Decision
Command State
making +

Messages
Attack ( DeathStarPath , Squadron )

Traveling
Sent ( Squadron, Destination )
Travel ( Squadron, Destination )

Traveling
Arrived ( Squadron, Destination )

Traveling

Fighting
Fire ( DeathStarPath )

Fighting
Fire ( XWingPath )
Lost ( Squadron, XWing )

Messages
Attack ( DeathStarPath , Squadron )
Travel ( Squadron, Destination )
Sent ( Squadron, Destination )
Lost ( Squadron, Destination )
Fire ( XWingPath )

Algebras
Fire x Fighting Lost
Fighting x Lost Fighting

Algebras
Akka killing feature
!
receive as Partial Function
context.become()

Algebras
Think about functions
validating inputs
for some outputs

Algebras
Finite State Machine
!
For The Win

Algebras
NOW THE
CODE

akka-cluster akka-persistence
akka-actor

akka-actor
Idle
Attack

akka-actor
Arrived
Reporter
Affected

akka-actor
Arrived Reporter
Affected

akka-persistence
Idle
Attack

akka-persistence
Sent
Traveling

akka-persistence
Sent
Traveling
Eventlog

akka-persistence
Traveling
Sent
Eventlog

akka-persistence
Traveling
Sent
Eventlog
Reporter

akka-persistence
Traveling
Attack

akka-persistence
Traveling
Attack
By default
at-most-once delivery

akka-persistence
Traveling

akka-persistence
Traveling
Ack
at-least-once delivery

akka-persistence
Traveling
IFailedMasterException

akka-persistence
Idle
Sent
Eventlog
Attack Sent

akka-persistence
Traveling
Affected
Eventlog
Attack

akka-persistence
Traveling
Sent
Eventlog
Recovery from EventLog

akka-cluster

akka-cluster
Red squadron

akka-cluster
Blue squadron Red squadron
Green squadron

akka-cluster
Affected Affected
Blue squadron Red squadron
Affected Affected
Green squadron

Final notes
Aggregate hides
implementation
details
Implementation
is focused on a
bounded context of
the whole domain
Think about messages,
Focus your attention
on interaction
over data
The less actors have
interlocutors, the better.
Take care about
message senders.

Thanks
@xbucchiotty xbucchiotty@xebia.fr

Reactive Domain Driven Design - elsassjug

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Reactive Domain Driven Design - elsassjug

Semelhante a Reactive Domain Driven Design - elsassjug (10)

Mais de Publicis Sapient Engineering

Mais de Publicis Sapient Engineering (20)

Último

Último (20)

Reactive Domain Driven Design - elsassjug