Domain Modeling Made Functional (DevTernity 2022)

Domain Modeling
Made Functional
(DevTernity 2022)
@ScottWlaschin
fsharpforfunandprofit.com

Functional programming:
what is it good for?
• Mathematical things only

Functional programming:
what is it good for?
• Mathematical things only
• Interactive & collaborative domain modeling
• Representing a domain model accurately

Functional
Programming
Domain
Driven
Design

Part I
The importance of design

Input Output
Process
The software development process

Input Output
Process
Garbage in Garbage out

Input Output
Process
(reduce) Garbage in (reduced) Garbage out

• Borrow from Agile and DDD
• Agile contribution:
– Rapid feedback during design
• DDD contribution:
– Stakeholders have a shared mental model
– …which is also represented in the code
How can we do design right?

Domain Modeling Made Functional (DevTernity 2022)

Can you really make code
represent the domain?

What non-developers think source code looks like
and some C developers!

module CardGame =
type Suit = Club | Diamond | Spade | Heart
type Rank =Two |Three | Four | Five | Six | Seven | Eight
| Nine |Ten | Jack | Queen | King
type Card = Suit * Rank
type Hand = Card list
type Deck = Card list
type Player = { Name:string; Hand:Hand }
type Game = { Deck:Deck; Players: Player list }
type Deal = Deck –› (Deck * Card)
type PickupCard = (Hand * Card) –› Hand
Shared
language What DDD source code should look like

module CardGame =
* means a pair. Choose one from each type
list type is built in

Deal
(original)
Deck
(remaining)
Deck
(on table)
Card
Modeling an action with a function
type Deal = Deck -> (Deck * Card)
Input Output

Pickup Card
(updated)
Hand
(original)
Hand
(on table)
Card
Modeling an action with a function
type PickupCard = (Hand * Card) –> Hand
Input Output

module CardGame =

module CardGame =
Can non-programmers provide
useful feedback?

Rapid feedback during
the design stage

Building a shared mental model is an
interactive process

...

...
type Deal = ShuffledDeck –› (ShuffledDeck * Card)

...
type ShuffledDeck = Card list

...
type Shuffle = Deck –› ShuffledDeck

In the real world
Suit
Rank
Card
Hand
Deck
Player
Deal
In the code
Suit
Rank
Card
Hand
Deck
Player
Deal

In the real world
Suit
Rank
Card
Hand
Deck
Player
Deal
In the code
Suit
Rank
Card
Hand
Deck
Player
Deal
ShuffledDeck
Shuffle
ShuffledDeck
Shuffle


In the real world
Suit
Rank
Card
Hand
Deck
Player
Deal
In the code
Suit
Rank
Card
Hand
Deck
Player
Deal
PlayerController
DeckBase
AbstractCardProxyFactoryBean


Again: The process of building the
shared mental model is critical!
Collaboration!

Key DDD principle:
Communicate the design
in the code

type Contact = {
FirstName: string
MiddleInitial: string
LastName: string
EmailAddress: string
IsEmailVerified: bool
} // true if ownership of
// email address is confirmed

type Contact = {
FirstName: string
LastName: string
}
Prologue: which values are optional?

type Contact = {
FirstName: string
LastName: string
}
Prologue: what are the constraints?

type Contact = {
FirstName: string
LastName: string
}
Prologue: domain logic?

Prologue: F# can help
type Contact = {
FirstName: string
LastName: string
}

Part II
Understanding FP type systems

FP principle:
Composition everywhere

Composition = Make big things from small things

New types are built from smaller types by:
Composing with “AND”
Composing with “OR”

All languages have this.
Example: pairs, tuples, records
FruitSalad = One each of and and
Compose with “AND”
type FruitSalad = {
Apple: AppleVariety
Banana: BananaVariety
Cherry: CherryVariety
}

Snack = or or
Compose with “OR”
type Snack =
| Apple of AppleVariety
| Banana of BananaVariety
| Cherry of CherryVariety

A real world example
of composing types

Some requirements:
We accept three forms of payment:
Cash, PayPal, or Card.
For Cash we don't need any extra information
For PayPal we need a email address
For Cards we need a card type and card number

interface IPaymentMethod
{..}
class Cash() : IPaymentMethod
{..}
class PayPal(string emailAddress): IPaymentMethod
{..}
class Card(string cardType, string cardNo) : IPaymentMethod
{..}
In OO design you would probably implement it as an
interface and a set of subclasses, like this:

type EmailAddress = string
type CardNumber = string
In FP you would probably implement by
composing types, like this:

type EmailAddress = ...
type CardNumber = …
type CardType = Visa | Mastercard
type CreditCardInfo = {
CardType : CardType
CardNumber : CardNumber
}

type CardNumber = ...
type CardType = ...
type CreditCardInfo = ...
type PaymentMethod =
| Cash
| PayPal of EmailAddress
| Card of CreditCardInfo

type CardType = ...
| Cash
type PaymentAmount = decimal
type Currency = EUR | USD

type CardType = ...
| Cash
type PaymentAmount = decimal
type Currency = EUR | USD
type Payment = {
Amount : PaymentAmount
Currency : Currency
Method : PaymentMethod }

Part III
Domain modeling
with composable types

type Contact = {
FirstName: string
LastName: string
} // true if ownership of
// email address is confirmed
This looks suspiciously like
database-driven design...

type Contact = {
Name: PersonalName
Email: EmailContactInfo }
"A contact has a name AND email info"
"Like this?..."

type Contact = {
Name: PersonalName
"A contact has a name AND email info"
We have two new concepts already!

type PersonalName = {
FirstName: string
LastName: string
}
"What's a personal name?"

FirstName: string
LastName: string
}
required
required
optional
"What's required or optional?"

Null is not the same as “optional”
Length
string –› int
“a”
“b”
“c”
1
2
3
“a”
“b”
“c”
null

Null is not the same as “optional”
Length
string –› int
“a”
“b”
“c”
null
1
2
3

Null is not allowed
Length
string –› int
“a”
“b”
“c”
null
1
2
3
X

A better way for optional values
+
=
“a”
“b”
“c”
“a”
“b”
“c”
missing
or
Tag with “Nothing”
type OptionalString =
| SomeString of string
| Nothing

type Option<'T> =
| Some of 'T
| None

FirstName: string
MiddleInitial: Option<string>
LastName: string
}

FirstName: string
MiddleInitial: string option
LastName: string
}

Modeling simple values and
constrained values

Modeling simple values
• Avoid "Primitive Obsession"
• Simple values should not be modelled with
primitive types like "int" or "string" or "float"
"Does 'float' have
something to do
with water?"

Modeling constrained values
• It's rare to have an unconstrained int or string:
– An EmailAddress must not be empty,
it must match a pattern
– A PhoneNumber must not be empty,
it must match a pattern
– A CustomerId must be a positive integer

Is an EmailAddress just a string? No!
Is a CustomerId just a int? No!

type EmailAddress = EmailAddress of string
Use wrapper types to keep domain concepts
distinct from their representation
type CustomerId = CustomerId of int
type String50 = String50 of string

type EmailAddress = EmailAddress of string
type PhoneNumber = PhoneNumber of string
type CustomerId = CustomerId of int
type OrderId = OrderId of int
Two benefits:
- Clearer domain modelling
- Can't mix them up accidentally

Implementing constructors
for constrained types

let createEmailAddress (s:string) =
if s.Contains("@")
then (EmailAddress s)
else ?
createEmailAddress:
string –› EmailAddress

let createEmailAddress (s:string) =
if s.Contains("@")
then Some (EmailAddress s)
else None
createEmailAddress:
string –› EmailAddress option

type String50 = String50 of string
let createString50 (s:string) =
if s.Length <= 50
then Some (String50 s)
else None
createString50 :
string –› String50 option

type OrderLineQty = OrderLineQty of int
let createOrderLineQty qty =
if qty > 0 && qty <= 99
then Some (OrderLineQty qty)
else None
createOrderLineQty:
int –› OrderLineQty option

The "Contact" challenge,
after first refactor

type Contact = {
FirstName: string
LastName: string
}

type Contact = {
FirstName: string
MiddleInitial: string option
LastName: string
}
Use option type for
potentially missing values

type Contact = {
FirstName: String50
MiddleInitial: String1 option
LastName: String50
EmailAddress: EmailAddress
}
Use wrapper types
instead of primitives

FirstName : String50
MiddleInitial : String1 option
LastName : String50 }
type EmailContactInfo = {
EmailAddress : EmailAddress
IsEmailVerified : bool }
Also acts as "consistency boundaries"
2 different
domain concepts

What about this?

• Rule 1: If the email is changed, the verified flag
must be reset to false.
• Rule 2: The verified flag can only be set by a
special verification service

Listen closely to what the domain expert says...
type EmailContactInfo =
| Unverified of EmailAddress
| Verified of ???
So model it as a choice
"An email address is either
Verified OR Unverified"

"Email contact info is either Verified OR Unverified"
| Verified of ???

type VerifiedEmail = VerifiedEmail of EmailAddress
"there is no problem that can’t be
solved by wrapping it in another type"
Q: Is a verified email different from an unverified email?
Are there different business rules?
A: Yes, it must not be
mixed up with unverified.

"Email contact info is either Verified OR Unverified"
| Verified of VerifiedEmail

type VerificationService =
(EmailAddress * VerificationHash) –› VerifiedEmail option
So model it as a function
Q: Where do we get
Verified emails from?
A: A special
verification process

type VerifiedEmail =
VerifiedEmail of EmailAddress
Q: Are the business rules clear now?

Those business rules are automatically enforced by the design!

The "Contact" challenge,
completed

FirstName: String50
MiddleInitial: String1 opt
LastName: String50 }
type Contact = {
Name: PersonalName

Refactoring towards
deeper insight

type SendPasswordReset =
EmailAddress -> ...
If emailAddress.IsVerified then
send password
else
error "this should never happen"
Business rule: Only send password resets to verified emails
"this should never happen" 

type VerifiedEmail = ...
type SendPasswordReset =
VerifiedEmail -> ...
Business rule: Only send password resets to verified emails

Part IV
Encoding business rules with types
"Make illegal states unrepresentable!"
–Yaron Minsky

type Contact = {
Name: Name
Email: EmailContactInfo
Address: PostalContactInfo
}

type Contact = {
Name: Name
Email: EmailContactInfo
Address: PostalContactInfo
}
New rule:
“A contact must have an email or a postal address”

type Contact = {
Name: Name
Email: EmailContactInfo option
Address: PostalContactInfo option
}
New rule:

Let’s make illegal states
unrepresentable!

implies:
• email address only, or
• postal address only, or
• both email address and postal address

type ContactInfo =
| EmailOnly of EmailContactInfo
| AddrOnly of PostalContactInfo
| EmailAndAddr of EmailContactInfo * PostalContactInfo
type Contact = {
Name: Name
ContactInfo : ContactInfo }

Composable types are almost as awesome as this

Collaboration is two-way.
It's OK to push back

“A contact must have at least one way of being contacted”

“A contact must have at least one way of being contacted”
type Contact = {
Name: Name
PrimaryContactInfo: ContactInfo
SecondaryContactInfo: ContactInfo option }
type ContactInfo =
| Email of EmailContactInfo
| Addr of PostalContactInfo

Summary
• Represent the shared mental model in code
– The developers should become domain experts too
– Design collaboratively to build the shared mental
model
• Designs will evolve
– Embrace change. This is not Big Design Up Front
– Refactor towards deeper insight
– Static types give you confidence to make changes

Summary
• Use the power of a composable type system
– Choices rather than inheritance
– Options instead of null
– Avoid primitive types
– Model constraints with new types
– Make illegal states unrepresentable

Slides and video at fsharpforfunandprofit.com/ddd
Thanks!

Domain Modeling Made Functional (DevTernity 2022)

More Related Content

What's hot (20)

Similar to Domain Modeling Made Functional (DevTernity 2022) (9)

More from Scott Wlaschin (20)

Recently uploaded (20)

Domain Modeling Made Functional (DevTernity 2022)