Successfully reported this slideshow.
Upcoming SlideShare
×

# Functional and Algebraic Domain Modeling

801 views

Published on

DDD using functional and algebraic techniques (presented at DDD Europe 2018)

Published in: Software
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

### Functional and Algebraic Domain Modeling

1. 1. Functional and Algebraic Domain Modeling Debasish Ghosh @debasishg
2. 2. Functional and Algebraic Domain Modeling Debasish Ghosh @debasishg
3. 3. Functional Programming • programming with pure functions • a function’s output is solely determined by the input (much like mathematical functions) • no assignment, no side-effects •(pure) mapping between values • functions compose • expression-oriented programming
4. 4. Functional and Algebraic Domain Modeling Debasish Ghosh @debasishg
5. 5. What is an Algebra ? Algebra is the study of algebraic structures In mathematics, and more speciﬁcally in abstract algebra, an algebraic structure is a set (called carrier set or underlying set) with one or more ﬁnitary operations deﬁned on it that satisﬁes a list of axioms -Wikipedia (https://en.wikipedia.org/wiki/Algebraic_structure)
6. 6. Set A ϕ : A × A → A fo r (a, b) ∈ A ϕ(a, b) a ϕ b given a binary operation for specific a, b or The Algebra of Sets
7. 7. Algebraic Thinking • Thinking and reasoning about code in terms of the data types and the operations they support without considering a bit about the underlying implementations • f: A => B and g: B => C, we should be able to reason that we can compose f and g algebraically to build a larger function h: A => C •algebraic composition
8. 8. Functional and Algebraic Domain Modeling Debasish Ghosh @debasishg
9. 9. Domain Modeling
10. 10. Domain Modeling (Functional)
11. 11. 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 speciﬁc 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)
12. 12. https://msdn.microsoft.com/en-us/library/jj591560.aspx
13. 13. A Bounded Context • has a consistent vocabulary • a set of domain behaviors modeled as functions on domain objects implemented as types • each of the behaviors honor a set of business rules • related behaviors grouped as modules
14. 14. Domain Model = ∪(i) Bounded Context(i) Bounded Context = { m[T1,T2,..] | T(i) ∈ Types } Module = { f(x,y,..) | p(x,y) ∈ Domain Rules } • domain function • on an object of types x, y, .. • composes with other functions • closed under composition • business rules
15. 15. • Functions / Morphisms • Types / Sets • Composition • Rules / Laws algebra
16. 16. explicit veriﬁable • types • type constraints • functions between types • type constraints • more constraints if you have DT • algebraic property based testing (algebra of types, functions & laws of the solution domain model) Domain Model Algebra
17. 17. What is meant by the algebra of a type ? •Nothing •Unit •Boolean •Byte •String
18. 18. What is meant by the algebra of a type ? •Nothing -> 0 •Unit -> 1 •Boolean -> 2 •Byte -> 256 •String -> a lot
19. 19. What is meant by the algebra of a type ? •(Boolean, Unit) •(Byte, Unit) •(Byte, Boolean) •(Byte, Byte) •(String, String)
20. 20. What is meant by the algebra of a type ? •(Boolean, Unit) -> 2x1 = 2 •(Byte, Unit) -> 256x1 = 256 •(Byte, Boolean) -> 256x2 = 512 •(Byte, Byte) -> 256x256 = 65536 •(String, String) -> a lot
21. 21. What is meant by the algebra of a type ? • Quiz: Generically, how many inhabitants can we have for a type (a, b)? • Answer: 1 inhabitant for each combination of a’s and b’s (a x b)
22. 22. Product Types • Ordered pairs of values one from each type in the order speciﬁed - this and that • Can be generalized to a ﬁnite product indexed by a ﬁnite set of indices
23. 23. Product Types in Scala type Point = (Int, Int) val p = (10, 12) case class Account(no: String, name: String, address: String, dateOfOpening: Date, dateOfClosing: Option[Date] )
24. 24. What is meant by the algebra of a type ? •Boolean or Unit •Byte or Unit •Byte or Boolean •Byte or Byte •String or String
25. 25. What is meant by the algebra of a type ? •Boolean or Unit -> 2+1 = 3 •Byte or Unit -> 256+1 = 257 •Byte or Boolean -> 256+2 = 258 •Byte or Byte -> 256+256 = 512 •String or String -> a lot
26. 26. Sum Types • Model data structures involving alternatives - this or that • A tree can have a leaf or an internal node which, is again a tree • In Scala, a sum type is usually referred to as an Algebraic DataType (ADT)
27. 27. Sum Types in Scala sealed trait Shape case class Circle(origin: Point, radius: BigDecimal) extends Shape case class Rectangle(diag_1: Point, diag_2: Point) extends Shape
28. 28. Sum Types are Expressive • Booleans - true or false • Enumerations - sum types may be used to deﬁne ﬁnite enumeration types, whose values are one of an explicitly speciﬁed ﬁnite set • Optionality - the Option data type in Scala is encoded using a sum type • Disjunction - this or that, the Either data type in Scala • Failure encoding - the Try data type in Scala to indicate that the computation may raise an exception
29. 29. sealed trait InstrumentType case object CCY extends InstrumentType case object EQ extends InstrumentType case object FI extends InstrumentType sealed trait Instrument { def instrumentType: InstrumentType } case class Equity(isin: String, name: String, issueDate: Date, faceValue: Amount) extends Instrument { final val instrumentType = EQ } case class FixedIncome(isin: String, name: String, issueDate: Date, maturityDate: Option[Date], nominal: Amount) extends Instrument { final val instrumentType = FI } case class Currency(isin: String) extends Instrument { final val instrumentType = CCY }
30. 30. De-structuring with Pattern Matching def process(i: Instrument) = i match { case Equity(isin, _, _, faceValue) => // .. case FixedIncome(isin, _, issueDate, _, nominal) => // .. case Currency(isin) => // .. }
31. 31. Exhaustiveness Check
32. 32. Sum Types and Domain Models • Models heterogeneity and heterogenous data structures are ubiquitous in a domain model • Allows modeling of expressive domain types in a succinct and secure way - secure by construction • Pattern matching makes encoding domain logic easy and expressive
33. 33. – Robert Harper in Practical Foundations of Programming Languages “The absence of sums is the origin of C. A. R. Hoare’s self-described ‘billion dollar mistake,’ the null pointer”
34. 34. More algebra of types • Exponentiation - f: A => B has b^a inhabitants • Taylor Series - Recursive Data Types • Derivatives - Zippers • …
35. 35. Scaling of the Algebra • Since a function is a mapping from the domain of types to the co-domain of types, we can talk about the algebra of a function • A module is a collection of related functions - we can think of the algebra of a module as the union of the algebras of all functions that it encodes • A domain model (one bounded context) can be loosely thought of as a collection of modules, which gives rise to the connotation of a domain model algebra
36. 36. Algebraic Composition • Functions compose based on types, which means .. • Algebras compose • Giving rise to larger algebras / functions, which in turn implies .. • We can construct larger domain behaviors by composing smaller behaviors
37. 37. Algebras are Ubiquitous • Generic, parametric and hence usable on an inﬁnite set of data types, including your domain model’s types
38. 38. Algebras are Ubiquitous • Generic, parametric and hence usable on an inﬁnite set of data types, including your domain model’s types • Clear separation between the contract (the algebra) and its implementations (interpreters)
39. 39. Algebras are Ubiquitous • Generic, parametric and hence usable on an inﬁnite set of data types, including your domain model’s types • Clear separation between the contract (the algebra) and its implementations (interpreters) • Standard vocabulary (like design patterns)
40. 40. Algebras are Ubiquitous • Generic, parametric and hence usable on an inﬁnite set of data types, including your domain model’s types • Clear separation between the contract (the algebra) and its implementations (interpreters) • Standard vocabulary (like design patterns) • Existing set of reusable algebras offered by the standard libraries
41. 41. Roadmap to a Functional and Algebraic Model 1. Identify domain behaviors 2. Identify the algebras of functions (not implementation) 3. Compose algebras to form larger behaviors - follow the types depending on the semantics of compositionality.We call this behavior a program that models the use case 4. Plug in concrete types to complete the implementation
42. 42. Domain Model = ∪(i) Bounded Context(i) Bounded Context = { m[T1,T2,..] | T(i) ∈ Types } Module = { f(x,y,..) | p(x,y) ∈ Domain Rules } • domain function • on an object of types x, y • composes with other functions • closed under composition • business rules
43. 43. Domain Model = ∪(i) Bounded Context(i) Bounded Context = { m[T1,T2,..] | T(i) ∈ Types } Module = { f(x,y,..) | p(x,y) ∈ Domain Rules } • domain function • on an object of types x, y • composes with other functions • closed under composition • business rules Domain Algebra Domain Algebra
44. 44. Given all the properties of algebra, can we consider algebraic composition to be the basis of designing, implementing and modularizing domain models ?
45. 45. Client places order - ﬂexible format 1
46. 46. Client places order - ﬂexible format Transform to internal domain model entity and place for execution 1 2
47. 47. Client places order - ﬂexible format Transform to internal domain model entity and place for execution Trade & Allocate to client accounts 1 2 3
48. 48. def fromClientOrder: ClientOrder => Order def execute(market: Market, brokerAccount: Account) : Order => List[Execution] def allocate(accounts: List[Account]) : List[Execution] => List[Trade] trait Trading { } trait TradeComponent extends Trading with Logging with Auditing algebra of domain behaviors / functions functions aggregate upwards into modules modules aggregate into larger modules
49. 49. .. so we have a decent algebra of our module, the names reﬂect the appropriate artifacts from the domain (ubiquitous language), the types are well published and we are quite explicit in what the behaviors do ..
50. 50. 1. Compositionality - How do we compose the 3 behaviors that we published to generate trade in the market and allocate to client accounts ? 2. Side-effects - We need to compose them alongside all side-effects that form a core part of all non trivial domain model implementations
51. 51. • Error handling ? • throw / catch exceptions is not RT • Partiality ? • partial functions can report runtime exceptions if invoked with unhandled arguments (violates RT) • Reading conﬁguration information from environment ? • may result in code repetition if not properly handled • Logging ? • side-effects Side-effects
52. 52. Side-effects • Database writes • Writing to a message queue • Reading from stdin / ﬁles • Interacting with any external resource • Changing state in place
53. 53. modularity side-effects don’t compose
54. 54. .. the semantics of compositionality .. in the presence of side-effects
55. 55. Algebra to the rescue ..
56. 56. Algebra to the rescue .. of types
57. 57. Abstract side-effects into data type constructors
58. 58. Abstract side-effects into data type constructors, which we call Effects ..
59. 59. Option[A] Either[A,B] (partiality) (disjunction) List[A] (non-determinism) Reader[E,A] (read from environment aka dependency Injection) Writer[W,A] (logging) State[S,A] (state management) IO[A] (external side-effects) .. and there are many many more ..
60. 60. F[A] The answer that the effect computesThe additional stuff modeling the computation
61. 61. • The F[_] that we saw is an opaque type - it has no denotation till we give it one • The denotation that we give to F[_] depends on the semantics of compositionality that we would like to have for our domain model behaviors
62. 62. def fromClientOrder: ClientOrder => F[Order] def execute(market: Market, brokerAccount: Account) : Order => F[List[Execution]] def allocate(accounts: List[Account]) : List[Execution] => F[List[Trade]] trait Trading[F[_]] { } Effect Type
63. 63. • Just the Algebra • No denotation, no concrete type • Explicitly stating that we have eﬀectful functions here def fromClientOrder: ClientOrder => F[Order] def execute(market: Market, brokerAccount: Account) : Order => F[List[Execution]] def allocate(accounts: List[Account]) : List[Execution] => F[List[Trade]] trait Trading[F[_]] { } Effect Type
64. 64. • .. we have intentionally kept the algebra open for interpretation .. • .. there are use cases where you would like to have multiple interpreters for the same algebra ..
65. 65. The Program def tradeGeneration[M[_]: Monad](T: Trading[M]) = for { order <- T.fromClientOrder(cor) executions <- T.execute(m1, ba, order) trades <- T.allocate(List(ca1, ca2, ca3), executions) } yield trades
66. 66. class TradingInterpreter[F[_]] (implicit me: MonadError[F, Throwable]) extends Trading[F] { def fromClientOrder: ClientOrder => F[Order] = makeOrder(_) match { case Left(dv) => me.raiseError(new Exception(dv.message)) case Right(o) => o.pure[F] } def execute(market: Market, brokerAccount: Account) : Order => F[List[Execution]] = ... def allocate(accounts: List[Account]) : List[Execution] => F[List[Trade]] = ... } One Sample Interpreter
67. 67. • .. one lesson in modularity - commit to a concrete implementation as late as possible in the design .. • .. we have just indicated that we want a monadic effect - we haven’t committed to any concrete monad type even in the interpreter ..
70. 70. The Program def tradeGenerationLoggable[M[_]: Monad] (T: Trading[M], L: Logging[M]) = for { _ <- L.info("starting order processing") order <- T.fromClientOrder(cor) executions <- T.execute(m1, ba, order) trades <- T.allocate(List(ca1, ca2, ca3), executions) _ <- L.info("allocation done") } yield trades object TradingComponent extends TradingInterpreter[IO] object LoggingComponent extends LoggingInterpreter[IO] tradeGenerationLoggable(TradingComponent, LoggingComponent).unsafeRunSync
71. 71. Raise the level of abstraction trait Trading[F[_]] { def fromClientOrder : Kleisli[F, ClientOrder, Order] def execute(market: Market, brokerAccount: Account) : Kleisli[F, Order, List[Execution]] def allocate(accounts: List[Account]) : Kleisli[F, List[Execution], List[Trade]] }