Domain Modeling Made Functional
summary
Shows how F#’s type system—option type, discriminated union and generics—encodes business rules so invalid states can’t exist at compile time. Builds concrete types: EmailAddress, String50, Quantity (0–99), VerifiedEmail with a private constructor, and ContactInfo as a union so “must have email or postal” is guaranteed. Uses pattern matching and immutability to replace runtime validation, cuts unit tests by catching errors at compile time, and demonstrates working examples and code on FSharp.org / ndcsydney resources.
AI-written summary · about
chapters (35)
- 0:00Intro
- 1:40Why do domain modeling
- 2:51How can we reduce the garbage in
- 6:10Domain modelling made functional
- 6:23Domain driven design
- 7:11Outline
- 7:34Is Functional Programming Scary
- 9:28Functional World
- 10:02Functional Program
- 12:02Domain During Design
- 12:23Shared Mental Model
- 14:22Context
- 15:38Terminology
- 18:33Code
- 19:13Persistence
- 20:44Algebraic Type System
- 21:02Composable Type System
- 24:32Sum Type
- 25:12Payment Methods
- 26:05Pattern Matching
- 27:59Type Checking
- 29:26Optional Values
- 32:06Optional Boolean
- 32:35Optional String
- 33:13Required Choice
- 33:34Email Addresses
- 33:52Customer IDs
- 35:10Email Address
- 36:48Spring
- 37:09Ecommerce
- 39:10Business Rules
- 46:33Contact Information
- 46:53Static Types
- 48:10Summary
- 49:29FSHARP
related talks
01h 03mExposing the not-so-secret practices of the cult of DDD
01h 03mExposing the not-so-secret practices of the cult of DDD
01h 01mMoving IO to the edges of your app: Functional Core, Imperative Shell
31mFable.Form: Unlock your Forms Super Powers
46mFinite-state machines? Your compiler wants in!
25mMaking Impossible States Impossible
49mBetter software design with domain modelling
55mF# and Fable: re-think web development