From Functional to Reactive patterns in domain modeling Debasish - - PowerPoint PPT Presentation

▶
from functional to reactive
SMART_READER_LITE
LIVE PREVIEW

From Functional to Reactive patterns in domain modeling Debasish - - PowerPoint PPT Presentation

May 30, 2023 97 likes •1.37k views

From Functional to Reactive patterns in domain modeling Debasish Ghosh @debasishg Tuesday, 6 October 15 Tuesday, 6 October 15 Domain Modeling Tuesday, 6 October 15 Domain Modeling (Functional) Tuesday, 6 October 15 Domain Modeling

slide-1
SLIDE 1

From Functional to Reactive

patterns in domain modeling

Debasish Ghosh @debasishg

Tuesday, 6 October 15

slide-2
SLIDE 2

Tuesday, 6 October 15

slide-3
SLIDE 3

Domain Modeling

Tuesday, 6 October 15

slide-4
SLIDE 4

Domain Modeling (Functional)

Tuesday, 6 October 15

slide-5
SLIDE 5

Domain Modeling (Responsive) (Functional)

Tuesday, 6 October 15

slide-6
SLIDE 6

Domain Modeling (Responsive) (Functional) (Elastic)

Tuesday, 6 October 15

slide-7
SLIDE 7

Domain Modeling (Responsive) (Functional) (Elastic) (Resilient)

Tuesday, 6 October 15

slide-8
SLIDE 8

Domain Modeling (Responsive) (Functional) (Elastic) (Resilient) (Reactive)

Tuesday, 6 October 15

slide-9
SLIDE 9

What is a domain model ?

A domain model in problem solving and software engineering is a conceptual model of all the topics related to a specific problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain. It does not describe the solutions to the problem.

Wikipedia (http://en.wikipedia.org/wiki/Domain_model)

Tuesday, 6 October 15

slide-10
SLIDE 10

The Functional Lens ..

“domain API evolution through algebraic composition”

Tuesday, 6 October 15

slide-11
SLIDE 11

The Functional Lens ..

“domain API evolution through algebraic composition”

(Reactive)

Tuesday, 6 October 15

slide-12
SLIDE 12

Agenda

  • Formalizing a domain model
  • Domain model algebra
  • From functional to algebraically reactive
  • Beyond algebra
  • Actors and domain models
  • Reactive streams - typesafe & compositional

Tuesday, 6 October 15

slide-13
SLIDE 13

Tuesday, 6 October 15

slide-14
SLIDE 14

Tuesday, 6 October 15

slide-15
SLIDE 15

Your domain model is a function

Tuesday, 6 October 15

slide-16
SLIDE 16

Your domain model is a function

Tuesday, 6 October 15

slide-17
SLIDE 17

Your domain model is a collection of functions

Tuesday, 6 October 15

slide-18
SLIDE 18

Your domain model is a collection of functions

some simpler models are ..

Tuesday, 6 October 15

slide-19
SLIDE 19

https://msdn.microsoft.com/en-us/library/jj591560.aspx

Tuesday, 6 October 15

slide-20
SLIDE 20

A Bounded Context

  • has a consistent vocabulary
  • a set of domain behaviors modeled as

functions on domain objects implemented as types

  • related behaviors grouped as modules

Tuesday, 6 October 15

slide-21
SLIDE 21

Domain Model = ∪(i) Bounded Context(i)

Tuesday, 6 October 15

slide-22
SLIDE 22

Domain Model = ∪(i) Bounded Context(i)

Bounded Context = { f(x) | p(x) ∈ Domain Rules }

Tuesday, 6 October 15

slide-23
SLIDE 23

Domain Model = ∪(i) Bounded Context(i)

Bounded Context = { f(x) | p(x) ∈ Domain Rules }

  • domain function
  • on an object of type x
  • composes with other functions
  • closed under composition
  • business rules

Tuesday, 6 October 15

slide-24
SLIDE 24
  • Functions / Morphisms
  • Types / Sets
  • Composition
  • Rules / Laws

Tuesday, 6 October 15

slide-25
SLIDE 25
  • Functions / Morphisms
  • Types / Sets
  • Composition
  • Rules / Laws

algebra

Tuesday, 6 October 15

slide-26
SLIDE 26

Domain Model Algebra

Tuesday, 6 October 15

slide-27
SLIDE 27

Domain Model Algebra (algebra of types, functions & laws)

Tuesday, 6 October 15

slide-28
SLIDE 28

Domain Model Algebra (algebra of types, functions & laws) explicit

  • types
  • type constraints
  • expression in terms of other generic algebra

Tuesday, 6 October 15

slide-29
SLIDE 29

Domain Model Algebra (algebra of types, functions & laws) explicit verifiable

  • types
  • type constraints
  • expression in terms of other generic algebra
  • type constraints
  • more constraints if you have DT
  • algebraic property based testing

Tuesday, 6 October 15

slide-30
SLIDE 30

close debit

  • pen

...

Domain Behaviors

Tuesday, 6 October 15

slide-31
SLIDE 31

Amount Account Balance Customer

... ... ...

close debit

  • pen

...

Domain Behaviors Domain Types

Tuesday, 6 October 15

slide-32
SLIDE 32

Amount Account Balance Customer

... ... ...

close debit

  • pen

...

market regulations tax laws brokerage commission rates

...

Domain Behaviors Domain Types Domain Rules

Tuesday, 6 October 15

slide-33
SLIDE 33

Amount Account Balance Customer

... ... ...

close debit

  • pen

...

market regulations tax laws brokerage commission rates

...

Domain Behaviors Domain Types Domain Rules

Monoid Monad

...

Generic Algebraic Structures

Tuesday, 6 October 15

slide-34
SLIDE 34

Amount Account Balance Customer

... ... ...

close debit

  • pen

...

market regulations tax laws brokerage commission rates

...

Domain Behaviors Domain Types Domain Rules

Monoid Monad

...

Generic Algebraic Structures

Domain Algebra

Tuesday, 6 October 15

slide-35
SLIDE 35

Domain Model = ∪(i) Bounded Context(i)

Bounded Context = { f(x) | p(x) ∈ Domain Rules }

  • domain function
  • on an object of type x
  • composes with other functions
  • closed under composition
  • business rules

Domain Algebra

Domain Algebra

Tuesday, 6 October 15

slide-36
SLIDE 36
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations

Algebra is the binding contract

Bounded Context

Tuesday, 6 October 15

slide-37
SLIDE 37
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations

Algebra is the binding contract

Bounded Context

Reactive

Tuesday, 6 October 15

slide-38
SLIDE 38

Conference Reservations Program Management Badge Printing Co Co

Domain Algebra A Domain Algebra B Domain Algebra C

  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations

Tuesday, 6 October 15

slide-39
SLIDE 39
  • Algebras don’t unify across bounded

contexts

  • Decoupled in space and time
  • Separate vocabulary
  • Types break down

Tuesday, 6 October 15

slide-40
SLIDE 40

Conference Reservations Program Management Badge Printing Co Co

Domain Algebra A Domain Algebra B Domain Algebra C

  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations

Protocols

Tuesday, 6 October 15

slide-41
SLIDE 41

Conference Reservations Program Management Badge Printing Co Co

Domain Algebra A Domain Algebra B Domain Algebra C

  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations

Protocols

Reactive

Tuesday, 6 October 15

slide-42
SLIDE 42

Being Reactive

Elasticity (responsive under varying load) Resilience (responsive in the face of failures) Message-driven (loose coupling, isolation thru async message passing) Responsive (through bounded latency)

Tuesday, 6 October 15

slide-43
SLIDE 43

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType): AccountOp[Account] def close(no: String, closeDate: Option[Date]): AccountOp[Account] def debit(no: String, amount: Amount): AccountOp[Account] def credit(no: String, amount: Amount): AccountOp[Account] //.. }

Tuesday, 6 October 15

slide-44
SLIDE 44

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType): AccountOp[Account] def close(no: String, closeDate: Option[Date]): AccountOp[Account] def debit(no: String, amount: Amount): AccountOp[Account] def credit(no: String, amount: Amount): AccountOp[Account] //.. } Module Name

Tuesday, 6 October 15

slide-45
SLIDE 45

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType): AccountOp[Account] def close(no: String, closeDate: Option[Date]): AccountOp[Account] def debit(no: String, amount: Amount): AccountOp[Account] def credit(no: String, amount: Amount): AccountOp[Account] //.. } Module Name Parameterized on types

Tuesday, 6 October 15

slide-46
SLIDE 46

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType): AccountOp[Account] def close(no: String, closeDate: Option[Date]): AccountOp[Account] def debit(no: String, amount: Amount): AccountOp[Account] def credit(no: String, amount: Amount): AccountOp[Account] //.. } Module Name Parameterized on types Operation return type - either a successfully constructed type

  • r a list of errors

Tuesday, 6 October 15

slide-47
SLIDE 47

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType): AccountOp[Account] def close(no: String, closeDate: Option[Date]): AccountOp[Account] def debit(no: String, amount: Amount): AccountOp[Account] def credit(no: String, amount: Amount): AccountOp[Account] //.. } Module Name Parameterized on types Operation return type - either a successfully constructed type

  • r a list of errors

Operations - domain behaviors

Tuesday, 6 October 15

slide-48
SLIDE 48

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType): AccountOp[Account] def close(no: String, closeDate: Option[Date]): AccountOp[Account] def debit(no: String, amount: Amount): AccountOp[Account] def credit(no: String, amount: Amount): AccountOp[Account] //.. } Module Name Parameterized on types Operation return type - either a successfully constructed type

  • r a list of errors

Operations - domain behaviors

explicit & verifiable algebra

Tuesday, 6 October 15

slide-49
SLIDE 49
  • Parametric - parameterized on types
  • Statically Typed
  • Modular and hence unit testable
  • Composable

Tuesday, 6 October 15

slide-50
SLIDE 50

def transfer(from: String, to: String, amount: Amount) : AccountOp[(Account, Account)] = for { a <- debit(from, amount) b <- credit(to, amount) } yield ((a, b))

Composable

Tuesday, 6 October 15

slide-51
SLIDE 51

Composable

trait BankingService[Account, Amount, Balance] extends AccountService[Account, Amount, Balance] with InterestPostingService[Account, Amount] with InterestCalculation[Account, Amount] with TaxCalculation[Amount]

Tuesday, 6 October 15

slide-52
SLIDE 52

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open( no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType ): AccountRepository => AccountOp[Account] //.. }

Tuesday, 6 October 15

slide-53
SLIDE 53

trait AccountService[Account, Amount, Balance] { type AccountOp[A] = NonEmptyList[String] \/ A def open( no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType ): AccountRepository => AccountOp[Account] //.. }

change the algebra to add functionality

Tuesday, 6 October 15

slide-54
SLIDE 54

trait AccountService[Account, Amount, Balance] { type Valid[A] = NonEmptyList[String] \/ A type AccountOp[A] = Kleisli[Valid, AccountRepository, A] def open( no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType ): AccountOp[Account] //.. }

more algebra, more functionality, more succinct

Tuesday, 6 October 15

slide-55
SLIDE 55
  • Design should not have any contention or

central bottlenecks that tend to hamper the progress of the system

Being Reactive

Tuesday, 6 October 15

slide-56
SLIDE 56
  • If your domain service publishes APIs that

does blocking calls to underlying databases and blocks the central thread of user interaction, you face the specter of unbounded latency

Being Reactive

Tuesday, 6 October 15

slide-57
SLIDE 57

Blocking Kills

Tuesday, 6 October 15

slide-58
SLIDE 58

Blocking Kills

Make your APIs elastic enough so that the perceived response to the user is not affected by the current load on the system

Tuesday, 6 October 15

slide-59
SLIDE 59

Elasticity (responsive under varying load) Resilience (responsive in the face of failures) Message-driven (loose coupling, isolation thru async message passing) Responsive (through bounded latency)

Tuesday, 6 October 15

slide-60
SLIDE 60
  • Without foregoing the benefits of algebraic

reasoning with types

Being Reactive

Tuesday, 6 October 15

slide-61
SLIDE 61

Enter Futures ..

Tuesday, 6 October 15

slide-62
SLIDE 62

Enter Futures ..

  • A future is the essence of asynchronous non

blocking computation

Tuesday, 6 October 15

slide-63
SLIDE 63

Enter Futures ..

  • A future is the essence of asynchronous non

blocking computation

  • Futures compose

Tuesday, 6 October 15

slide-64
SLIDE 64

Enter Futures ..

  • A future is the essence of asynchronous non

blocking computation

  • Futures compose
  • Futures have an algebra

Tuesday, 6 October 15

slide-65
SLIDE 65

Enter Futures ..

  • A future is the essence of asynchronous non

blocking computation

  • Futures compose
  • Futures have an algebra
  • Organize concurrent code around futures

safely and in a compositional way

Tuesday, 6 October 15

slide-66
SLIDE 66
  • In our use case we would like to augment
  • ur domain algebra with future based APIs
  • Just like an Either or a Kleisli, we

would like to have asynchrony as yet another stackable effect within our computation

Goals towards Reactive API

Tuesday, 6 October 15

slide-67
SLIDE 67

Stacking of Effects

Tuesday, 6 October 15

slide-68
SLIDE 68

Stacking of Effects

Tuesday, 6 October 15

slide-69
SLIDE 69

type Response[A] = String \/ Option[A] val count: Response[Int] = some(10).right for { maybeCount <- count } yield { for { c <- maybeCount // use c } yield c }

Monad Transformers

Tuesday, 6 October 15

slide-70
SLIDE 70

type Response[A] = String \/ Option[A] val count: Response[Int] = some(10).right for { maybeCount <- count } yield { for { c <- maybeCount // use c } yield c } type Error[A] = String \/ A type Response[A] = OptionT[Error, A] val count: Response[Int] = 10.point[Response] for { c <- count // use c : c is an Int here } yield (())

Monad Transformers

Tuesday, 6 October 15

slide-71
SLIDE 71

type Response[A] = String \/ Option[A] val count: Response[Int] = some(10).right for { maybeCount <- count } yield { for { c <- maybeCount // use c } yield c } type Error[A] = String \/ A type Response[A] = OptionT[Error, A] val count: Response[Int] = 10.point[Response] for{ c <- count // use c : c is an Int here } yield (())

Monad Transformers richer algebra

Tuesday, 6 October 15

slide-72
SLIDE 72

Monad Transformers

  • collapses the stack and gives us a single

monad to deal with

  • order of stacking is important though

Tuesday, 6 October 15

slide-73
SLIDE 73

trait AccountService[Account, Amount, Balance] { type Valid[A] = EitherT[Future, NonEmptyList[String], A] type AccountOp[A] = Kleisli[Valid, AccountRepository, A] def open( no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType ): AccountOp[Account] //.. }

Tuesday, 6 October 15

slide-74
SLIDE 74

trait AccountService[Account, Amount, Balance] { type Valid[A] = EitherT[Future, NonEmptyList[String], A] type AccountOp[A] = Kleisli[Valid, AccountRepository, A] def open( no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType ): AccountOp[Account] //.. }

Tuesday, 6 October 15

slide-75
SLIDE 75

Tuesday, 6 October 15

slide-76
SLIDE 76

trait AccountService[Account, Amount, Balance] { type Valid[A] = EitherT[Future, NonEmptyList[String], A] type AccountOp[A] = Kleisli[Valid, AccountRepository, A] def open( no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType ): AccountOp[Account] //.. }

Reactive .. Algebraically

Tuesday, 6 October 15

slide-77
SLIDE 77

class AccountServiceInterpreter extends AccountService[Account, Amount, Balance] { def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType) = kleisli[Valid, AccountRepository, Account] { (repo: AccountRepository) => EitherT { Future { repo.query(no) match { //.. } } } } //.. }

Tuesday, 6 October 15

slide-78
SLIDE 78

class AccountServiceInterpreter extends AccountService[Account, Amount, Balance] { def open(no: String, name: String, rate: Option[BigDecimal],

  • peningDate: Option[Date],

accountType: AccountType) = kleisli[Valid, AccountRepository, Account] { (repo: AccountRepository) => EitherT { Future { repo.query(no) match { //.. } } } } //.. }

normal logic

Tuesday, 6 October 15

slide-79
SLIDE 79

We introduced a whole new effect of asynchrony to implement reactive traits in our domain model API algebra & implementation just by composing with another type without any change in the core domain logic. This is the essence of typed functional programming. We have types that model effects functionally and we can just stack them up in the proper

  • rder that we need.

Tuesday, 6 October 15

slide-80
SLIDE 80

Advantages

  • We are still in the statically typed land even

with asynchronous behaviors baked into

  • ur APIs
  • We can reason about our program

statically

  • We can compose asynchronous

components to form larger abstractions

Tuesday, 6 October 15

slide-81
SLIDE 81

for { _ <- open(..) _ <- credit(..) d <- debit(..) } yield d

Reactive & algebraic patterns in domain modeling

Tuesday, 6 October 15

slide-82
SLIDE 82

for { _ <- open(..) _ <- credit(..) d <- debit(..) } yield d

Reactive & algebraic patterns in domain modeling

  • Compositional by types

Tuesday, 6 October 15

slide-83
SLIDE 83

for { _ <- open(..) _ <- credit(..) d <- debit(..) } yield d

Reactive & algebraic patterns in domain modeling

  • Compositional by types
  • Individual operations

sequential as they thread through the comprehension

Tuesday, 6 October 15

slide-84
SLIDE 84

for { _ <- open(..) _ <- credit(..) d <- debit(..) } yield d

Reactive & algebraic patterns in domain modeling

  • Compositional by types
  • Individual operations

sequential as they thread through the comprehension

  • Composed operation doesn’t

block the main thread of execution

Tuesday, 6 October 15

slide-85
SLIDE 85

Reactive & algebraic patterns in domain modeling

Tuesday, 6 October 15

slide-86
SLIDE 86

trait PortfolioService { type PFOperation[A] = Kleisli[Future, AccountRepository, Seq[A]] def getCurrencyPortfolio(no: String, asOf: Date) : PFOperation[Balance] def getEquityPortfolio(no: String, asOf: Date) : PFOperation[Balance] def getFixedIncomePortfolio(no: String, asOf: Date) : PFOperation[Balance] }

Reactive & algebraic patterns in domain modeling

Tuesday, 6 October 15

slide-87
SLIDE 87

val ccyPF: Future[Seq[Balance]] = getCurrencyPortfolio(accountNo, asOf)(AccountRepository) val eqtPF: Future[Seq[Balance]] = getEquityPortfolio(accountNo, asOf)(AccountRepository) val fixPF: Future[Seq[Balance]] = getFixedIncomePortfolio(accountNo, asOf)(AccountRepository) val portfolio: Future[Portfolio] = for { c <- ccyPF e <- eqtPF f <- fixPF } yield CustomerPortfolio(accountNo, asOf, c ++ e ++ f)

Reactive & algebraic patterns in domain modeling

Tuesday, 6 October 15

slide-88
SLIDE 88

Be Algebraic, as long as you can ..

Tuesday, 6 October 15

slide-89
SLIDE 89

Beyond Algebra - Reactive Protocols

Tuesday, 6 October 15

slide-90
SLIDE 90

Conference Reservations Program Management Badge Printing Co Co

Domain Algebra A Domain Algebra B Domain Algebra C

  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations

Protocols

Reactive

Tuesday, 6 October 15

slide-91
SLIDE 91

Conference Reservations Program Management Badge Printing Co Co

Domain Algebra A Domain Algebra B Domain Algebra C

  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations
  • Ubiquitous language
  • Entities
  • Value Objects
  • Functions on objects
  • Domain Rules
  • Schema
  • Operations

Protocols

Reactive

Elasticity (responsive under varying load) Resilience (responsive in the face of failures) Message-driven (loose coupling, isolation thru async message passing) Responsive (through bounded latency)

Tuesday, 6 October 15

slide-92
SLIDE 92

Asynchronous Messaging

Tuesday, 6 October 15

slide-93
SLIDE 93

Asynchronous Messaging

Tuesday, 6 October 15

slide-94
SLIDE 94

Asynchronous Messaging

Tuesday, 6 October 15

slide-95
SLIDE 95

Asynchronous Messaging

Tuesday, 6 October 15

slide-96
SLIDE 96

Actors and Domain Models

Tuesday, 6 October 15

slide-97
SLIDE 97

Actors and Domain Models

Powerful

Tuesday, 6 October 15

slide-98
SLIDE 98

Actors and Domain Models

Powerful Un-algebraically Powerful

Tuesday, 6 October 15

slide-99
SLIDE 99

Actors and Domain Models

Powerful Un-algebraically Powerful Gain power at one semantic level but lose the power of reasoning

Tuesday, 6 October 15

slide-100
SLIDE 100

Using actors indiscriminately throughout your domain model makes algebraic reasoning hard

Tuesday, 6 October 15

slide-101
SLIDE 101

fork: A => Future[A] map: (A => B) => (Future[A] => Future[B]) join: Future[Future[A]] => Future[A]

Tuesday, 6 October 15

slide-102
SLIDE 102

receive: Any => Unit

Tuesday, 6 October 15

slide-103
SLIDE 103

Use the least powerful abstraction that does the job

Tuesday, 6 October 15

slide-104
SLIDE 104

For domain model resilience, choose futures over actors when you can ..

Tuesday, 6 October 15

slide-105
SLIDE 105
  • As an implementation artifact to protect

shared mutable state

  • Centralized failure management

Actors and Domain Models

Tuesday, 6 October 15

slide-106
SLIDE 106

import scala.collection.mutable.{ Map => MMap } class Summarizer extends Actor with ActorSubscriber with Logging { private val balance = MMap.empty[String, Balance] def receive = { case OnNext(data: Transaction) => updateBalance(data) case LogSummaryBalance => logger.info("Balance: " + balance) } def updateBalance(data: Transaction) = balance.get(data.accountNo).fold { balance += .. } { b => balance += .. } } shared mutable state here updated

Tuesday, 6 October 15

slide-107
SLIDE 107

Centralized Failure Management

  • Supervisor hierarchies that manages failures
  • Kill, restart, suspend / resume
  • No more messy failure handling code

scattered throughout

  • Requires careful upfront design though

Tuesday, 6 October 15

slide-108
SLIDE 108

Being Reactive

Elasticity (responsive under varying load) Resilience (responsive in the face of failures) Message-driven (loose coupling, isolation thru async message passing) Responsive (through bounded latency)

Tuesday, 6 October 15

slide-109
SLIDE 109

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

Tuesday, 6 October 15

slide-110
SLIDE 110

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level low level

Tuesday, 6 October 15

slide-111
SLIDE 111

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped low level

Tuesday, 6 October 15

slide-112
SLIDE 112

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped non-compositional low level

Tuesday, 6 October 15

slide-113
SLIDE 113

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped non-compositional low level un-algebraic

Tuesday, 6 October 15

slide-114
SLIDE 114

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped non-compositional low level un-algebraic higher

Tuesday, 6 October 15

slide-115
SLIDE 115

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped non-compositional low level un-algebraic higher dsl

Tuesday, 6 October 15

slide-116
SLIDE 116

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped non-compositional low level un-algebraic higher dsl flow as first class abstraction

Tuesday, 6 October 15

slide-117
SLIDE 117

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped non-compositional low level un-algebraic higher dsl flow as first class abstraction separate definition from execution

Tuesday, 6 October 15

slide-118
SLIDE 118

Modeling Domain Workflows

Actor Actor Actor Actor Actor Actor message message message message message message message

low level untyped non-compositional low level un-algebraic higher dsl flow as first class abstraction separate definition from execution

Reactive Streams

Tuesday, 6 October 15

slide-119
SLIDE 119

Akka Streams

Source

Pipeline starts here. Source[+Out, +Mat] takes data from input & has a single output

Sink

Pipeline ends here. Sink[+In, +Mat] has a single input to be written into

Flow

Basic transformation abstraction. Flow[-In, +Out, +Mat] has 1 input & 1 output. Mat is the actor materializer

Runnable Graph

The entire topology ready to run

Tuesday, 6 October 15

slide-120
SLIDE 120

Business Use Case - The Domain Model

Tuesday, 6 October 15

slide-121
SLIDE 121

Implementation topology with Akka Streams

Tuesday, 6 October 15

slide-122
SLIDE 122

val graph = FlowGraph.closed(netTxnSink) { implicit b => ns => import FlowGraph.Implicits._ val accountBroadcast = b.add(Broadcast[Account](2)) val txnBroadcast = b.add(Broadcast[Transaction](2)) val merge = b.add(Merge[Transaction](2)) val accounts = Flow[String].map(queryAccount(_, AccountRepository)) val bankingTxns = Flow[Account].mapConcat(getBankingTransactions) val settlementTxns = Flow[Account].mapConcat(getSettlementTransactions) val validation = Flow[Transaction].map(validate) accountNos ~> accounts ~> accountBroadcast ~> bankingTxns ~> merge ~> validation ~> txnBroadcast ~> ns accountBroadcast ~> settlementTxns ~> merge txnBroadcast ~> audit }

Tuesday, 6 October 15

slide-123
SLIDE 123

graph.run()

Tuesday, 6 October 15

slide-124
SLIDE 124

https://www.manning.com/books/functional-and-reactive- domain-modeling

Tuesday, 6 October 15

slide-125
SLIDE 125

Thank You!

Tuesday, 6 October 15

slide-126
SLIDE 126

Tuesday, 6 October 15