Domain Modeling Made Functional (KanDDDinsky 2019)

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

Domain Modeling
Made Functional
(KanDDDinsky 2019)
@ScottWlaschin
fsharpforfunandprofit.com

Functional
Programming
Domain
Driven
Design

Functional programming is good for...
Boring
Line Of Business
Applications
(BLOBAs)

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

• 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?

Can you really make code
represent the domain?

What non-developers think source code looks like

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
Sharedlanguage 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

...

...
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
PlayerManager
DeckBase
AbstractCardProxyFactoryBean


Key DDD principle:
Communicate the design
in the code

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: what groups are atomic?

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
An introduction to “algebraic” typesAn introduction to “algebraic” types

FP principle:
Types are not classes

The Tunnel of
Transformation
Function
apple -> banana
A function is a thing which
transforms inputs to outputs

So, what is a type then?
A type is a just a name
for a set of things
Set of
valid inputs
Set of
valid outputs
Function

Set of
valid inputs
Set of
valid outputs
Function
1
2
3
4
5
6
This is type
"integer"
for a set of things

Set of
valid inputs
Set of
valid outputs
Function
This is type
"string"
"abc"
"but"
"cobol"
"double"
"end"
"float"
for a set of things

Set of
valid inputs
Set of
valid outputs
Function
This is type
"Person"
Donna Roy
Javier Mendoza
Nathan Logan
Shawna Ingram
Abel Ortiz
Lena Robbins
GordonWood
for a set of things

Set of
valid inputs
Set of
valid outputs
Function
This is type
"Fruit"
for a set of things

Set of
valid inputs
Set of
valid outputs
Function
This is a type of
Fruit->Fruit functions
for a set of things

FP principle:
Composition everywhere

All pieces are designed to be connected

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

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, Check, or Card.
For Cash we don't need any extra information
For Checks we need a check number
For Cards we need a card type and card number

interface IPaymentMethod
{..}
class Cash() : IPaymentMethod
{..}
class Check(int checkNo): 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 CheckNumber = int
type CardNumber = string
In FP you would probably implement by composing
types, like this:

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

type CardNumber = ...
type CardType = ...
type CreditCardInfo = ...
type PaymentMethod =
| Cash
| Check of CheckNumber
| 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 }

What are types for?
An annotation to a value for type checking
type AddOne: int –› int
Domain modelling tool

STATICALLY TYPE ALL
THE THINGS

Part III
Domain modeling
with composable types
What can we do with this type system?

type PersonalName = {
FirstName: string
LastName: string
}
required
required
optional

Length
string –› int
“a”
“b”
“c”
1
2
3
“a”
“b”
“c”
null

Length
string –› int
“a”
“b”
“c”
null
1
2
3

Length
string –› int
“a”
“b”
“c”
null
1
2
3
X

+=
“a”
“b”
“c”
“a”
“b”
“c”
missing
or
Tag with “Nothing”
type OptionalString =
| SomeString of string
| Nothing

FirstName: string
LastName: string
}
type Option<'T> =
| Some of 'T
| None

FirstName: string
MiddleInitial: Option<string>
LastName: string
}
type Option<'T> =
| Some of 'T
| None

FirstName: string
MiddleInitial: string option
LastName: string
}
type Option<'T> =
| Some of 'T
| None

Modeling simple values and
constrained values

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

Modeling constrained values
• Rare to have an unbounded integer or string!
Generally constrained in some way:
– Emails must not be empty, must match a pattern
– CustomerIds must be positive

type Email = Email of string
Is an EmailAddress just a string? No!
Is a CustomerId just a int? No!
Use wrapper types to keep them distinct
type CustomerId = CustomerId of int

type EmailAddress = EmailAddress of string
type PhoneNumber = PhoneNumber of string
type CustomerId = CustomerId of int
type OrderId = OrderId of int

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,
revisited

type Contact = {
FirstName: string
LastName: string
}

type Contact = {
FirstName: string
MiddleInitial: string option
LastName: string
}

type Contact = {
FirstName: String50
MiddleInitial: String1 option
LastName: String50
EmailAddress: EmailAddress
}

type Contact = {
CustomerId : CustomerId
FirstName: String50
MiddleInitial: String1 option
LastName: String50
}
Add an id here
2 different
aggregates
Aggregates a.k.a. "consistency boundaries"

FirstName : String50
MiddleInitial : String1 option
LastName : String50 }
type EmailContactInfo = {
EmailAddress : EmailAddress
IsEmailVerified : bool }
2 different
aggregates

What about this?
FirstName : String50
MiddleInitial : String1 option
LastName : String50 }
EmailAddress : EmailAddress
IsEmailVerified : bool }

• 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
IsEmailVerified: bool }

type VerifiedEmail =
VerifiedEmail of EmailAddress
type VerificationService =
(EmailAddress * VerificationHash) –› VerifiedEmail option

type EmailContactInfo =
| Unverified of EmailAddress
| Verified of VerifiedEmail

Those business rules are automatically enforced!

The "Contact" challenge,
completed

type EmailAddress = ...
FirstName: String50
MiddleInitial: String1 opt
LastName: String50 }
type Contact = {
Name: PersonalName
Email: EmailContactInfo }

FirstName: String50
MiddleInitial: String1 opt
LastName: String50 }
type Contact = {
Name: PersonalName
Email: EmailContactInfo }
type EmailAddress = ...

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

Part IV
Encoding business rules with types

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:

"Make illegal states unrepresentable!"
–Yaron Minsky

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

Communication 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

type ContactInfo =
| Email of EmailContactInfo
| Addr of PostalContactInfo
| Facebook of FacebookInfo
| SMS of PhoneNumber

Summary
• Use code to represent the shared mental model
and ubiquitous language
• Designs will evolve. Embrace change.
– Refactor towards deeper insight
– Static types give you confidence to make changes
• Use the power of a composable type system
– Choices rather than inheritance
– Options instead of null
– Wrappers for constrained types
– Make illegal states unrepresentable

If you liked this talk:
• "Domain Modeling Made Functional"
– fsharpforfunandprofit.com/ddd
• More videos
– fsharpforfunandprofit.com/video
Thanks!
Twitter: @ScottWlaschin

Domain Modeling Made Functional (KanDDDinsky 2019)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Domain Modeling Made Functional (KanDDDinsky 2019)

Similaire à Domain Modeling Made Functional (KanDDDinsky 2019) (8)

Plus de Scott Wlaschin

Plus de Scott Wlaschin (16)

Dernier

Dernier (20)

Domain Modeling Made Functional (KanDDDinsky 2019)