Domain Modeling Functional Patterns Financial Domain

Functional Patterns in
Domain Modeling
with examples from the Financial Domain
@debasishg
https://github.com/debasishg
http://debasishg.blogspot.com
Wednesday, 5 November 14

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)

Rich domain
models
State Behavior
Class
• Class models the domain abstraction
• Contains both the state and the
behavior together
• State hidden within private access
specifier for fear of being mutated
inadvertently
• Decision to take - what should go inside
a class ?
• Decision to take - where do we put
behaviors that involve multiple classes ?
Often led to bloated service classes
State Behavior

• Algebraic Data Type (ADT) models the
domain abstraction
• Contains only the defining state as
immutable values
• No need to make things “private” since
we are talking about immutable values
• Nothing but the bare essential
definitions go inside an ADT
• All behaviors are outside the ADT in
modules as functions that define the
domain behaviors
Lean domain
models
Immutable
State
Behavior
Immutable
State
Behavior
Algebraic Data Types Functions in modules

Rich domain
models
State Behavior
Class
• We start with the class design
• Make it sufficiently “rich” by putting all
related behaviors within the class, used to
call them fine grained abstractions
• We put larger behaviors in the form of
services (aka managers) and used to call
them coarse grained abstractions
State Behavior

Lean domain
models
Immutable
State
Behavior
• We start with the functions, the
behaviors of the domain
• We define function algebras using types
that don’t have any implementation yet
(we will see examples shortly)
• Primary focus is on compositionality that
enables building larger functions out of
smaller ones
• Functions reside in modules which also
compose
• Entities are built with algebraic data
types that implement the types we used in
defining the functions
Immutable
State
Behavior
Algebraic Data Types Functions in modules

Domain Model
Elements
• Entities & Value Objects - modeled with
types
• Behaviors - modeled with functions
• Domain rules - expressed as constraints
& validations
• Bounded Context - delineates
subsystems within the model
• Ubiquitous Language

.. and some Patterns
• Domain object lifecycle patterns
Aggregates - encapsulate object
references
Factories - abstract object creation &
management
Repositories - manage object persistence
& queries

.. some more Patterns
• Refactoring patterns
Making implicit concepts explicit
Intention revealing interfaces
Side-effect free functions
Declarative design
Specification for validation

The Functional Lens ..

Why Functional ?
• Ability to reason about your code - virtues
of being pure & referentially transparent
• Increased modularity - clean separation of
state and behavior
• Immutable data structures
• Concurrency

Problem Domain

Bank
Account
Trade
Customer
...
...
...
Problem Domain
...
entities

place
order Problem Domain
Bank
Account
Trade
Customer
...
...
...
do trade
process
execution
...
entities
behaviors

place
Bank
Account
Trade
Customer
...
...
...
do trade
process
execution
...
market
regulations
tax laws
brokerage
commission
rates ...
entities
behaviors
laws

place
Solution Domain
behaviors • Functions
do trade
process
execution
...
• On Types
• Constraints

place
Solution Domain
do trade
process
execution
...
• On Types
• Constraints
Algebra
• Morphisms
• Sets
• Laws

place
Solution Domain
do trade
process
execution
...
• On Types
• Constraints
Algebra
• Morphisms
• Sets
• Laws
Compose for larger abstractions

A Monoid
An algebraic structure
having
• an identity element
• a binary associative
operation
trait Monoid[A] {
def zero: A
def op(l: A, r: => A): A
}
object MonoidLaws {
def associative[A: Equal: Monoid]
(a1: A, a2: A, a3: A): Boolean = //..
def rightIdentity[A: Equal: Monoid]
(a: A) = //..
def leftIdentity[A: Equal: Monoid]
(a: A) = //..
}

Monoid Laws
An algebraic structure
havingsa
• an identity element
• a binary associative
operation
trait Monoid[A] {
def zero: A
def op(l: A, r: => A): A
}
object MonoidLaws {
def associative[A: Equal: Monoid]
(a1: A, a2: A, a3: A): Boolean = //..
def rightIdentity[A: Equal: Monoid]
(a: A) = //..
def leftIdentity[A: Equal: Monoid]
(a: A) = //..
}
satisfies
op(x, zero) == x and op(zero, x) == x
satisfies
op(op(x, y), z) == op(x, op(y, z))

.. and we talk about domain algebra, where the
domain entities are implemented with sets of
types and domain behaviors are functions that
map a type to one or more types. And
domain rules are the laws which define the
constraints of the business ..

Pattern #1: Functional Modeling encourages Algebraic API
Design which leads to organic evolution of domain
models

Client places order
- flexible format
1

Client places order
- flexible format
1 2
Transform to internal domain
model entity and place for execution

Client places order
- flexible format
1 2
Transform to internal domain
model entity and place for execution
Trade & Allocate to
client accounts
3

def clientOrders: ClientOrderSheet => List[Order]
def execute: Market => Account => Order => List[Execution]
def allocate: List[Account] => Execution => List[Trade]

Types out of thin air No implementation till now

Just some types & operations on those types
+
some laws governing those operations

Algebra of the API
Just some types & operations on those types
+
some laws governing those operations

Algebraic Design
• The algebra is the binding contract of the
API
• Implementation is NOT part of the algebra
• An algebra can have multiple interpreters
(aka implementations)
• The core principle of functional
programming is to decouple the algebra from
the interpreter

let’s mine some
patterns ..

let’s mine some
patterns ..
def execute(m: Market, broker: Account): Order => List[Execution]
def allocate(accounts: List[Account]): Execution => List[Trade]

let’s mine some
patterns ..
Function Composition with Effects

let’s mine some
It’s a Kleisli !
patterns ..

let’s mine some
patterns ..
def clientOrders: Kleisli[List, ClientOrderSheet, Order]
def execute(m: Market, b: Account): Kleisli[List, Order, Execution]
def allocate(acts: List[Account]): Kleisli[List, Execution, Trade]
Follow the types

let’s mine some
patterns ..
def tradeGeneration(
market: Market,
broker: Account,
clientAccounts: List[Account]) = {
clientOrders andThen
execute(market, broker) andThen
allocate(clientAccounts)
}
Implementation follows the specification

def tradeGeneration(
market: Market,
broker: Account,
clientAccounts: List[Account]) = {
clientOrders andThen
execute(market, broker) andThen
allocate(clientAccounts)
}
Implementation follows the specification
and we get the Ubiquitous Language for
free :-)
let’s mine some
patterns ..

Nouns first ? Really ?

Just as the doctor
ordered ..
✓Making implicit concepts
explicit
✓Intention revealing
interfaces
✓Side-effect free functions
✓Declarative design

Just as the doctor
ordered ..
✓types as the
Making implicit functions concepts
& explicit
patterns for
on
Claim: With these ✓glue we get all based binding Intention generic revealing
abstractions free using function composition
interfaces
✓Side-effect free functions
✓Declarative design

Pattern #2: DDD patterns like Factories & Specification
are part of the normal idioms of functional programming

/**
* allocates an execution to a List of client accounts
* generates a List of trades
*/
def allocate(accounts: List[Account]): Kleisli[List, Execution, Trade] =
kleisli { execution =>
accounts.map { account =>
makeTrade(account,
execution.instrument,
genRef(),
execution.market,
execution.unitPrice,
execution.quantity / accounts.size
)
}
}

/**
* allocates an execution to a List of client accounts
* generates a List of trades
*/
def allocate(accounts: List[Account]): Kleisli[List, Execution, Trade] =
kleisli { execution =>
accounts.map { account =>
makeTrade(account,
execution.instrument,
genRef(),
execution.market,
execution.unitPrice,
execution.quantity / accounts.size
)
}
}
Makes a Trade out of the
parameters passed
What about validations ?
How do we handle failures ?

case class Trade (account: Account,
instrument: Instrument,
refNo: String,
market: Market,
unitPrice: BigDecimal,
quantity: BigDecimal,
tradeDate: Date = today,
valueDate: Option[Date] = None,
taxFees: Option[List[(TaxFeeId, BigDecimal)]] = None,
netAmount: Option[BigDecimal] = None
)

must be > 0
case class Trade (account: Account,
refNo: String,
market: Market,
tradeDate: Date = today,
valueDate: Option[Date] = None,
taxFees: Option[List[(TaxFeeId, BigDecimal)]] = None,
netAmount: Option[BigDecimal] = None
)
must be > trade date

Monads ..

monadic validation pattern
def makeTrade(account: Account,
refNo: String,
market: Market,
td: Date = today,
vd: Option[Date] = None): ValidationStatus[Trade] = {
val trd = Trade(account, instrument, refNo,
market, unitPrice, quantity, td, vd)
val s = for {
_ <- validQuantity
_ <- validValueDate
t <- validUnitPrice
} yield t
s(trd)
}

refNo: String,
market: Market,
td: Date = today,
val s = for {
_ <- validQuantity
_ <- validValueDate
t <- validUnitPrice
} yield t
s(trd)
}
(monad
comprehension)

Smart Constructor : The
refNo: String,
market: Market,
td: Date = today,
Factory Pattern
(Chapter 6)
val s = for {
_ <- validQuantity
_ <- validValueDate
t <- validUnitPrice
} yield t
s(trd)
}
The Specification
Pattern
(Chapter 9)

let’s mine some more
patterns (with types) .. disjunction type (a sum
type ValidationStatus[S] = /[String, S]
type ReaderTStatus[A, S] = ReaderT[ValidationStatus, A, S]
object ReaderTStatus extends KleisliInstances with KleisliFunctions {
def apply[A, S](f: A => ValidationStatus[S]): ReaderTStatus[A, S]
= kleisli(f)
}
type) : either a valid object or a
failure message
monad transformer

monadic validation
pattern ..
def validQuantity = ReaderTStatus[Trade, Trade] { trade =>
if (trade.quantity < 0)
left(s"Quantity needs to be > 0 for $trade")
else right(trade)
}
def validUnitPrice = ReaderTStatus[Trade, Trade] { trade =>
if (trade.unitPrice < 0)
left(s"Unit Price needs to be > 0 for $trade")
else right(trade)
}
def validValueDate = ReaderTStatus[Trade, Trade] { trade =>
trade.valueDate.map(vd =>
if (trade.tradeDate after vd)
left(s"Trade Date ${trade.tradeDate} must be before value date $vd")
else right(trade)
).getOrElse(right(trade))
}

With Functional
Programming
• we implement all specific patterns in terms
of generic abstractions
• all these generic abstractions are based on
function composition
• and encourage immutability & referential
transparency

Pattern #3: Functional Modeling encourages
parametricity, i.e. abstract logic from specific types to
generic ones

case class Trade(
refNo: String,
tradeDate: Date,
valueDate: Date,
principal: Money,
taxes: List[Tax],
...
)

case class Trade(
refNo: String,
tradeDate: Date,
valueDate: Date,
principal: Money,
taxes: List[Tax],
...
)
case class Money(amount: BigDecimal, ccy: Currency) {
def +(m: Money) = {
sealed trait Currency
case object USD extends Currency
case object AUD extends Currency
case object SGD extends Currency
case object INR extends Currency
require(m.ccy == ccy)
Money(amount + m.amount, ccy)
}
def >(m: Money) = {
require(m.ccy == ccy)
if (amount > m.amount) this else m
}
}

case class Trade(
refNo: String,
tradeDate: Date,
valueDate: Date,
principal: Money,
taxes: List[Tax],
...
)
def netValue: Trade => Money = //..
Given a list of trades, find the total net valuation of all trades
in base currency

def inBaseCcy: Money => Money = //..
def valueTradesInBaseCcy(ts: List[Trade]) = {
ts.foldLeft(Money(0, baseCcy)) { (acc, e) =>
acc + inBaseCcy(netValue(e))
}
}

case class Transaction(id: String, value: Money)
Given a list of transactions for a customer, find the highest
valued transaction

case class Transaction(id: String, value: Money)
def highestValueTxn(txns: List[Transaction]) = {
txns.foldLeft(Money(0, baseCcy)) { (acc, e) =>
Given a list of transactions for a customer, find the highest
valued transaction
acc > e.value
}
}

fold on the collection
}
}
acc > e.value
}
}

zero on Money
associative binary
operation on Money
}
}
acc > e.value
}
}

Instead of the specific collection type (List), we
can abstract over the type constructor using
the more general Foldable
}
}
acc > e.value
}
}

look ma .. Monoid for Money !
}
}
acc > e.value
}
}

fold the collection on a monoid
Foldable abstracts over
the type constructor
Monoid abstracts over
the operation

def mapReduce[F[_], A, B](as: F[A])(f: A => B)
(implicit fd: Foldable[F], m: Monoid[B]) = fd.foldMap(as)(f)

def valueTradesInBaseCcy(ts: List[Trade]) =
mapReduce(ts)(netValue andThen inBaseCcy)
def highestValueTxn(txns: List[Transaction]) =
mapReduce(txns)(_.value)

trait Foldable[F[_]] {
def foldl[A, B](as: F[A], z: B, f: (B, A) => B): B
def foldMap[A, B](as: F[A], f: A => B)(implicit m: Monoid[B]): B =
foldl(as, m.zero, (b: B, a: A) => m.add(b, f(a)))
}
implicit val listFoldable = new Foldable[List] {
def foldl[A, B](as: List[A], z: B, f: (B, A) => B) = as.foldLeft(z)(f)
}

implicit def MoneyMonoid(implicit c: Currency) =
new Monoid[Money] {
def zero: Money = Money(BigDecimal(0), c)
def append(m1: Money, m2: => Money) = m1 + m2
}
implicit def MaxMoneyMonoid(implicit c: Currency) =
new Monoid[Money] {
def zero: Money = Money(BigDecimal(0), c)
def append(m1: Money, m2: => Money) = m1 > m2
}

def valueTradesInBaseCcy(ts: List[Trade]) =
mapReduce(ts)(netValue andThen inBaseCcy)
def highestValueTxn(txns: List[Transaction]) =
mapReduce(txns)(_.value)
This last pattern is inspired from Runar’s response on this SoF thread http://stackoverflow.com/questions/4765532/what-does-abstract-over-mean

Takeaways ..
• Moves the algebra from domain specific
abstractions to more generic ones
• The program space in the mapReduce
function is shrunk - so scope of error is
reduced
• Increases the parametricity of our program
- mapReduce is now parametric in type
parameters A and B (for all A and B)

When using functional modeling, always try to express
domain specific abstractions and behaviors in terms of more
generic, lawful abstractions. Doing this you make your
functions more generic, more usable in a broader context
and yet simpler to comprehend.
This is the concept of parametricity and is one of the

Use code “mlghosh2” for a 50% discount

Image
acknowledgements
• www.valuewalk.com
• http://bienabee.com
• http://www.ownta.com
• http://ebay.in
• http://www.clker.com
• http://homepages.inf.ed.ac.uk/wadler/
• http://en.wikipedia.org

Thank You!

Domain Modeling Functional Patterns Financial Domain

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Domain Modeling Functional Patterns Financial Domain

Similaire à Domain Modeling Functional Patterns Financial Domain (20)

Plus de Debasish Ghosh

Plus de Debasish Ghosh (7)

Dernier

Dernier (20)

Domain Modeling Functional Patterns Financial Domain