reactive domain driven design - elsassjug

• EBIA ALLIANCE = XEBIA + XEBIALABS + THIGA + UX REPUBLIC

Reactive

Domain Driven Design


The Objective


The red squadron


Characters

/Alliance /Red squadron

/Empire / DeathStar


Attackclass 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 ! def attack(deathStar){ ! deathStar.receiveTorpedoFrom(this) !!!! } }

Fighting


class DeathStar{ var healthPoints = 100 ! 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


Notification from XWing to Squadron

class XWing{ var healthPoints = 1 !!! def receiveTorpedoFrom(sender){ ! println(s”$this is dead”) } }


class XWing{ var healthPoints = 1 ! val squadron = parent ! def receiveTorpedoFrom(sender){ squadron.remove(this) println(s”$this is dead”) } }



class XWing{ var healthPoints = 1 ! val squadron = parent ! def receiveTorpedoFrom(sender){ squadron.remove(this) println(s”$this is dead”) } }

Remember

No bidirectional

references



class XWing{ var healthPoints = 1 ! val squadron = parent ! def receiveTorpedoFrom(sender){ squadron.remove(this) println(s”$this is dead”) } } What would be

visibility of remove?



class XWing{ var healthPoints = 1 ! ! def receiveTorpedoFrom(sender){ println(s”$this is dead”) } ! }



class XWing{ var healthPoints = 1 ! val life = Promise[Unit]() ! def receiveTorpedoFrom(sender){ life.success(null) println(s”$this is dead”) } ! def endOfLife = life.future }




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




class Squadron{ var xwings = Set[XWing]() ! xwings.foreach(xwing => xwing.endOfLife.map(_ => xwings -= xwing ) ) ! }Loosely coupled




class Squadron{ var xwings = Set[XWing]() ! xwings.foreach(xwing => xwing.endOfLife.map(_ => xwings -= deadXWing ) ) ! }Loosely coupled

But we starts with

asynchronous




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



Tasks

Notification from XWing to Squadron Notification from

Squadron to Alliance



class Alliance{ val squadrons = Seq[Squadron]() ! !!!!!!!}

class Squadron{ var xwings = Set[XWing]() ! xwings.foreach(xwing => xwing.endOfLife.map(_ => xwings -= deadXWing ) ) ! def alliance = ??? }

Notification from Squadron to Alliance



class Squadron{ var xwings = Set[XWing]() ! xwings.foreach(xwing => xwing.endOfLife.map(_ => xwings -= deadXWing ) ) ! def alliance = ??? }

Remember again

No bidirectional

references




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



class Alliance{ val squadrons = Seq[Squadron]() squadrons.foreach(squadron => squadron.listener += { updatedSquadron => { if(updatedSquadron.currentSize < 2){ updatedSquadron.retreat() } } } ) !!!!}

class Squadron{ var xwings = Set[XWing]() ! xwings.foreach(xwing => xwing.endOfLife.map(_ => 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




class Squadron{ var xwings = Set[XWing]() ! def retreat() = ??? !!!!!!}



class Squadron{ var xwings = Set[XWing]() ! def retreat() = { travelTo(base) } !!!!!}



class Squadron{ var xwings = Set[XWing]() def retreat() = { travelTo(base) } !!!!!}


That does not

stop XWings to

fire


class Squadron{ var fighting = false def retreat() = { figthing = false travelTo(base) } ! def attack(deathStar){ travel(deathStar) fighting = true do { xwings.foreach(_.attack(deathStar)) } while (deathStar.alive && fighting) } }


Will make

the tests

green


class Squadron{ var fighting = false def retreat() = { figthing = false travelTo(base) } ! def attack(deathStar){ travel(deathStar) fighting = true do { xwings.foreach(_.attack(deathStar)) } while (deathStar.alive && fighting) } }


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{ var xwings = Set[XWing]() ! xwings.foreach(xwing => xwing.endOfLife.map { _ => !! } ) !!!!!}



class Squadron{ var xwings = Set[XWing]() ! xwings.foreach(xwing => xwing.endOfLife.map { _ => notifyListeners() ! } ) ! def attack(deathStar: DeathStar){ ! travelTo(deathStar) notifyListeners() ! } ! def retreat(){ travelTo(base) notifyListeners() } }


Will make

the tests

green


Tasks




class Squadron{ var xwings = Set[XWing]() !! !!!!!}



class Squadron{ var xwings = Set[XWing]() ! status(“idle“) def attack(deathStar){ status(“traveling“) notifyListeners() ! travelTo(deathStar) status(“figthing“) notifyListeners() } ! … !!}


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


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


Technical core concepts

Aggregate

Bounded context


Aggregate

Bounded contexttransaction


code

scalability


code scalability


code scalability

Knight

Knight


Implementation is focused on a

bounded context of the whole domain

code scalability

Knight

Knight


code scalability


code scalability

Aggregate hides implementation

details


Aggregate

Bounded contexttransaction


code

scalability


transaction


transaction

?


transaction

Root entity ensures

consistency of the whole aggregate at any time


transaction

!

can see 4 XWings


transaction

!

can see 3 XWings

When the Alliance can see the changes?


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


Domain Driven Design ++

EventSourcing

CQRS


CQRSCommand 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

Command State (Aggregate)x (Actions) Events

Decision making

Events x State (Aggregate)

apply State (Aggregate)

+



Command State (Aggregate)x (Actions) Events

Decision making



You don’t even need to persist

complete aggregates state !

+



Command State (Aggregate)x Events

Decision making





Command State (Aggregate)x Events

Decision making



source: @thinkbeforecoding !

https://github.com/thinkbeforecoding/FsUno.Prod

https://github.com/thinkbeforecoding/FsUno.Prod


Command ≠ EventCommand ≠ Query


Command

ActionsEvent


Command

ActionsEvent

But where are the views?


Reporter

And the views?

You can keep specific views

inside aggregates. You’ll bother the root for

minor subjects. Lost(red-1)


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


Characters


/Empire / DeathStar


Actors


/Empire / DeathStar



Command State (Aggregate)x Actions Events

Decision making +


Messages

Attack ( DeathStarPath , Squadron )


Idle


Traveling

Sent ( Squadron, Destination )

Travel ( Squadron, Destination )


Traveling

Arrived ( Squadron, Destination )


Traveling




Fighting

Fire ( DeathStarPath )


Fighting

Fire ( DeathStarPath )Fire ( XWingPath )Lost ( Squadron, XWing )


Fire ( DeathStarPath )

Messages

Sent ( Squadron, Destination )Arrived ( Squadron, Destination )


Travel ( Squadron, Destination )

Attack ( DeathStarPath , Squadron )

Lost ( Squadron, Destination )

Fire ( XWingPath )


Algebras

Fire Fightingx Lost

Fighting Lostx Fighting


Algebras

Fire Fightingx Lost


Akka killing feature !

receive as Partial Function

context.become()


Algebras

Fire Fightingx Lost


Think about functions

validating inputs

for some outputs


Algebras

Fire Fightingx Lost


Finite State Machine !

For The Win


Algebras

Fire Fightingx Lost


NOW THE CODE



akka-actor

akka-cluster akka-persistence



akka-actor

Idle

Attack


akka-actor

IdleAttack


akka-actor

Idle

Attack


akka-actor

Arrived

Reporter

Affected


akka-actor

Arrived Reporter

Affected


akka-actor

Reporter

Affected

Arrived



akka-actor




akka-persistence

Idle

Attack


IdleAttack

akka-persistence


Idle

Attack

akka-persistence


Traveling

Sent

akka-persistence


Traveling

akka-persistence

Sent


Traveling

akka-persistence

Eventlog

Sent


Traveling

akka-persistence

EventlogSent


Traveling

akka-persistence

Reporter

EventlogSent


Traveling

akka-persistence

Attack


Traveling

akka-persistence

Attack

By default at-most-once delivery


Traveling

akka-persistence

Attack


Traveling

akka-persistence


Traveling

akka-persistence

Ack

at-least-once delivery


Traveling

akka-persistence


Traveling

akka-persistence

IFailedMasterException


Traveling

akka-persistence


Idle

akka-persistence

EventlogSent

SentAttack


Traveling

akka-persistence

EventlogAffected

Attack


Traveling

akka-persistence

EventlogSent

Recovery from EventLog



akka-actor




akka-cluster


akka-cluster

Red squadron


akka-cluster

Red squadronBlue squadron

Green squadron


akka-cluster

Red squadronBlue squadron

Green squadron

AffectedAffected

Affected Affected


akka-cluster

Red squadronBlue squadronAffectedAffected

Affected Affected

Green squadron


Final notesAggregate hides implementation

details



Think about messages, Focus your attention

on interaction over data

The less actors have interlocutors, the better.

Take care about message senders.


Thanks

@xbucchiotty [email protected]

reactive domain driven design - elsassjug

Software

alliance ebia alliance

xwingto squadron ebia

xwing ebia alliance

ux republicclass alliance

red squadron ebia alliance

class squadron

retreat ebia alliance

setsquadron ebia alliance