domain modeling with functions - an algebraic approach

Domain Modeling with Functions

an algebraic approach

Debasish Ghosh(@debasishg)

Wednesday, 23 September 15

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)


http://en.wikipedia.org/wiki/Domain_model

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


The Functional Lens ..

“domain API evolution through algebraic composition”


• Set of behaviors• Can be composed• Usually closed under composition

• Set of business rules

Domain Model = { f(x) | P(x) Є { domain rules }}

x has a type


Domain Model Algebra



(algebra of types, functions & laws)




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




explicit

verifiable

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

• type constraints• more constraints if you have DT• algebraic property based testing


Problem Domain


Bank

Account

Trade

Customer

......

...

Problem Domain

...

entities


Bank

Account

Trade

Customer

......

...

do trade

process execution

place order

Problem Domain

...

entities

behaviors


Bank

Account

Trade

Customer

......

...

do trade

process execution

place order

Problem Domain

...

market regulations

tax laws

brokerage commission

rates

...

entities

behaviors

laws


do trade

process execution

place orderProblem Domain

...

behaviors • Functions• On Types• Constraints

Solution Domain


do trade

process execution


...


Solution Domain

• Morphisms• Sets• Laws

Algebra


do trade

process execution


...


Solution Domain

• Morphisms• Sets• Laws

Algebra

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

satisfies op(x, zero) == x and op(zero, x) == x

satisfies op(op(x, y), z) == op(x, op(y, z))


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) = //..}


A Monoid• generic• domain independent• context unaware



A Monoidtrait Monoid[A] { def zero: A def op(l: A, r: => A): A}

• generic• domain independent• context unaware

implicit def MoneyPlusMonoid = new Monoid[Money] { def zero = //.. def op(m1: Money, m2: Money) = //..}

• context of the domain






(algebra)

(interpretation)






(algebra)

(interpretation)

(reusable across contexts)

(varies with context)


do trade

process execution

place order

...

Domain Behaviors


Bank

Account

Trade

Customer

......

...do trade

process execution

place order

...

Domain Behaviors Domain Types


Bank

Account

Trade

Customer

......

...do trade

process execution

place order

...

market regulations

tax laws


rates

...

Domain Behaviors Domain TypesDomain Rules


Bank

Account

Trade

Customer

......

...do trade

process execution

place order

...

market regulations

tax laws


rates

...


Monoid Monad ...

Generic Algebraic Structures


Bank

Account

Trade

Customer

......

...do trade

process execution

place order

...

market regulations

tax laws


rates

...


Monoid Monad ...

Generic Algebraic Structures

Domain Algebra


.. so 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 ..


Functional Modeling encourages Algebraic API Design which leads to organic evolution of domain models


Client places order- flexible format

1



Transform to internal domainmodel entity and place for execution

1 2



Transform to internal domainmodel entity and place for execution

Trade & Allocate toclient accounts

1 2

3


def clientOrders: ClientOrderSheet => List[Order]

def execute: Market => Account => Order => List[Execution]

def allocate: List[Account] => Execution => List[Trade]



def execute[Account <: BrokerAccount]: Market => Account => Order => List[Execution]

def allocate[Account <: TradingAccount]: List[Account] => Execution => List[Trade]





Types out of thin air No implementation till now

Type names resonate domain language





• Types (domain entities)• Functions operating on types (domain behaviors)• Laws (business rules)





• Types (domain entities)• Functions operating on types (domain behaviors)• Laws (business rules)

Algebra of the API


trait Trading[Account, Trade, ClientOrderSheet, Order, Execution, Market] {




def tradeGeneration(market: Market, broker: Account, clientAccounts: List[Account]) = ???}

parameterized on typesmodule


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)

• One of the core principles of functional programming is to decouple the algebra from the interpreter





let’s do some algebra ..



def execute(m: Market, broker: Account): Order => List[Execution]

def allocate(accounts: List[Account]): Execution => List[Trade]

let’s do some algebra ..


def f: A => List[B]

def g: B => List[C]

def h: C => List[D]

.. a problem of composition ..


.. a problem of composition with effects ..

def f: A => List[B]

def g: B => List[C]

def h: C => List[D]


def f[M: Monad]: A => M[B]

def g[M: Monad]: B => M[C]

def h[M: Monad]: C => M[D]

.. a problem of composition with effects that can be generalized ..





Define a mapping M[B] => B





m.map(f(a))(g)





m.map(f(a))(g) M[M[C]]





m.join(m.map(f(a))(g)) M[C]





andThen


.. the glue (combinator) ..

def andThen[M[_], A, B, C](f: A => M[B], g: B => M[C])

(implicit m: Monad[M]): A => M[C] = {(a: A) =>

m.join(m.map(f(a))(g))}


case class Kleisli[M[_], A, B](run: A => M[B]) {

def andThen[C](f: B => M[C])

(implicit M: Monad[M]): Kleisli[M, A, C] =

Kleisli((a: A) => M.flatMap(run(a))(f))}

.. function composition with Effects ..

It’s a Kleisli !


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



def execute(m: Market, broker: Account): Order => List[Execution]

def allocate(accounts: List[Account]): Execution => List[Trade]





Domain algebra composed with the categorical algebra of a Kleisli Arrow






.. that implements the semantics of our domain algebraically ..



def tradeGeneration( market: Market, broker: Account, clientAccounts: List[Account]) = {

clientOrders andThen execute(market, broker) andThen allocate(clientAccounts)

}

Implementation follows the specification

.. the complete trade generation logic ..


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 :-)

.. the complete trade generation logic ..


algebraic & functional

• Just Pure Functions. Lower cognitive load - don’t have to think of the classes & data members where behaviors will reside

• Compositional. Algebras compose - we defined the algebras of our domain APIs in terms of existing, time tested algebras of Kleislis and Monads





.. our algebra still doesn’t handle errors that may occur within our domain

behaviors ..



more algebra, more types



return type constructor



return type constructor

What happens in case the operation fails ?


Error handling as an Effect

• pure and functional

• with an explicit and published algebra

• stackable with existing effects




.. stacking of effects ..

M[List[_]]




M[List[_]]: M is a Monad


type Response[A] = String \/ Option[A]

val count: Response[Int] = some(10).rightfor { maybeCount <- count} yield { for { c <- maybeCount // use c } yield c}

Monad Transformers




type Error[A] = String \/ Atype 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




type Error[A] = String \/ Atype 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


Monad Transformers

• collapses the stack and gives us a single monad to deal with

• order of stacking is important though




case class ListT[M[_], A] (run: M[List[A]]) { //..


type StringOr[A] = String \/ Atype Valid[A] = ListT[StringOr, A]



def clientOrders: Kleisli[Valid, ClientOrderSheet, Order]

def execute(m: Market, b: Account): Kleisli[Valid, Order, Execution]

def allocate(acts: List[Account]): Kleisli[Valid, Execution, Trade]



def clientOrders: Kleisli[Valid, ClientOrderSheet, Order]

def execute(m: Market, b: Account): Kleisli[Valid, Order, Execution]

def allocate(acts: List[Account]): Kleisli[Valid, Execution, Trade]

.. a small change in algebra, a huge step for our domain model ..


def execute(market: Market, brokerAccount: Account) =

kleisli[List, Order, Execution] { order =>

order.items.map { item => Execution(brokerAccount, market, ..) }

}


private def makeExecution(brokerAccount: Account, item: LineItem, market: Market): String \/ Execution = //..

def execute(market: Market, brokerAccount: Account) =

kleisli[Valid, Order, Execution] { order =>

listT[StringOr](

order.items.map { item =>

makeExecution(brokerAccount, market, ..)

}.sequenceU

) }





.. the algebra ..





.. the algebra ..

functions


.. the algebra ..




types


.. the algebra ..

composition

def tradeGeneration(market: Market, broker: Account, clientAccounts: List[Account]) = {

clientOrders andThen execute(market, broker) andThen allocate(clientAccounts)}


.. the algebra ..

trait OrderLaw {

def sizeLaw: Seq[ClientOrder] => Seq[Order] => Boolean = { cos => orders => cos.size == orders.size }

def lineItemLaw: Seq[ClientOrder] => Seq[Order] => Boolean = { cos => orders => cos.map(instrumentsInClientOrder).sum == orders.map(_.items.size).sum }}

laws of the algebra (domain rules)


Domain Rules as Algebraic Properties

• part of the abstraction

• equally important as the actual abstraction

• verifiable as properties


.. domain rules verification ..

property("Check Client Order laws") =

forAll((cos: Set[ClientOrder]) => {

val orders = for { os <- clientOrders.run(cos.toList) } yield os

sizeLaw(cos.toSeq)(orders) == true

lineItemLaw(cos.toSeq)(orders) == true

})

property based testing FTW ..


more algebra, more types


a useful pattern for decoupling algebra from

implementationWednesday, 23 September 15

Repository

• store domain objects

• query domain objects

• single point of interface of the domain model


sealed trait AccountRepoF[+A]

case class Query[+A](no: String, onResult: Account => A) extends AccountRepoF[A]

case class Store[+A](account: Account, next: A) extends AccountRepoF[A]

case class Delete[+A](no: String, next: A) extends AccountRepoF[A]

algebra of the repository ..

• pure• compositional• implementation independent

continuation hole


object AccountRepoF { implicit val functor: Functor[AccountRepoF] = new Functor[AccountRepoF] {

def map[A,B](action: AccountRepoF[A])(f: A => B): AccountRepoF[B] =

action match { case Store(account, next) => Store(account, f(next)) case Query(no, onResult) => Query(no, onResult andThen f) case Delete(no, next) => Delete(no, f(next)) }

}}

define a functor for the algebra ..


object AccountRepoF { implicit val functor: Functor[AccountRepoF] = new Functor[AccountRepoF] {

def map[A,B](action: AccountRepoF[A])(f: A => B): AccountRepoF[B] =

action match { case Store(account, next) => Store(account, f(next)) case Query(no, onResult) => Query(no, onResult andThen f) case Delete(no, next) => Delete(no, f(next)) }

}}

define a functor for the algebra ..

you get a free monad ..

type AccountRepo[A] = Free[AccountRepoF, A]


lift your algebra into the context of the free monad ..

trait AccountRepository {

def store(account: Account): AccountRepo[Unit] = liftF(Store(account, ()))

def query(no: String): AccountRepo[Account] = liftF(Query(no, identity))

def delete(no: String): AccountRepo[Unit] = liftF(Delete(no, ()))

}


lift your algebra into the context of the free monad ..

trait AccountRepository {

def store(account: Account): AccountRepo[Unit] = liftF(Store(account, ()))

def query(no: String): AccountRepo[Account] = liftF(Query(no, identity))

def delete(no: String): AccountRepo[Unit] = liftF(Delete(no, ()))

def update(no: String, f: Account => Account): AccountRepo[Unit] = for { a <- query(no) _ <- store(f(a)) } yield ()

}


def open(no: String, name: String, openingDate: Option[Date]) = for {

_ <- store(Account(no, name, openingDate.get))

a <- query(no)

} yield a

build larger abstractions monadically ..

.. and you get back a free monad




a <- query(no)

} yield a


.. and you get back a free monad.. with 2 operations chained in sequence




a <- query(no)

} yield a


.. and you get back a free monad.. with 2 operations chained in sequence

.. just the algebra, no semantics


Essence of the Pattern

• We have built the entire model of computation without any semantics, just the algebra

• Just a description of what we intend to do

• Not surprising that it’s a pure abstraction


Essence of the Pattern

• Now we can provide as many interpreters as we wish depending on the usage / context

• 1 interpreter for testing that tests the repository actions against an in-memory data structure

• 1 interpreter for production that uses an RDBMS


a sample interpreter structure ..

def interpret[A](script: AccountRepo[A], ls: List[String]): List[String] = script.fold(_ => ls, {

case Query(no, onResult) => interpret(..)

case Store(account, next) => interpret(..)

case Delete(no, next) => interpret(..)

})

Interpret the whole abstraction and provide the implementation in context


Intuition ..

• The larger algebra formed from each individual algebra element is merely a collection without any interpretation, something like an AST

• The interpreter provides the context and the implementation of each of the algebra elements under that specific context


Takeaways ..


algebraic design

• evolution based on contracts / types / interfaces without any dependency on implementation


algebraic design

• evolves straight from the domain use cases using domain vocabulary (ubiquitous language falls in place because of this direct correspondence)


algebraic design

• modular and hence pluggable. Each of the API that we discussed can be plugged off the specific use case and independently used in other use cases


algebraic design

• pure, referentially transparent and hence testable in isolation


algebraic design

• compositional, composes with the domain algebra and with the other categorical algebras inheriting their semantics seamlessly into the domain model e.g. effectful composition with kleislis and fail-fast error handling with monads


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 fundamental building blocks of compositionality in FP.


Use code “mlghosh2” for a 50% discount


Thank You!


domain modeling with functions - an algebraic approach

Software