Domain Modeling Made Functional

What Hacker News says

1. JachMay 2026
   I think learning Common Lisp and learning Coalton are best done separately. For CL the usual reference if you already know how to program is PCL: https://gigamonkeys.com/book/ But the cookbook is invaluable as well: https://lispcookbook.github.io/cl-cookbook/ When it comes to interactive development, looking up resources about SLIME should help since a lot is transferable to the mine environment (or as I prefer, a vim+slimv environment) by having the REPL right there as well as the "beam" metaphor.

   For Coalton, I'm still casually exploring it myself. I'm less convinced by the main value propositions (I really like my dynamic typing and CLOS) but I still think it's an interesting language, and being on top of CL means I can mix using it where it makes more sense (even in the same file if I want) without having to abandon CL. I assume you've found the whirlwind tour/awesome-coalton examples for it.. I've seen some usage of it as a way to write "normal" mostly procedural-ish code but with declared types that you know will be checked and used for optimization, so it's sort of like writing PHP with types, or TypeScript, or even in some ways Java or C. e.g.:

       (declare add-two-ints (Integer * Integer -> Integer))
       (define (add-two-ints a b)
         (+ a b))
   

   And (add-two-ints 3.5 5) will type-mismatch.

   But I think Coalton's really meant to support writing programs in the style of statically typed languages like Haskell, Ocaml, and F#. Those languages are more than just the above add... style of declaring types, they're about using algebraic data types to model the problem and design your program in those terms. So I'd suggest finding a book or interesting tutorial or sample project in one of those languages, and seeing if you can figure out how to translate it into Coalton, because the Coalton material is still pretty sparse. I've had some success at this by reading "Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#". It really starts at the basics that I think Coalton sort of assumes you understand already. I'll share the main basic things I've taken from it, though I invite any correction.

   First, while in many languages we love to pass variables as naked ints and other native types around, making more use of the type system means you can make explicit domain types for these things. You could write something like (define-type-alias CustomerID Integer), and use CustomerID as a type in other types and function definitions. The downside is you don't get a nice constructor for it, and you can accidentally pass CustomerIDs to functions written as only expecting Integers. You can instead write (define-type CustomerID (CustomerID Integer)) and now you'll get a nice little constructor and type errors trying to pass these objects to functions expecting Integers. The downside is you'll need to extract any underlying values with pattern matching/destructuring in match expressions, function arguments, or flattened let expressions.

   define-type can be used to model a single thing (like an Integer) but it can also express an "or" relationship, or a "sum type", where a value can be one of several things. e.g.:

       (define-type PaymentMethod
         (CreditCard CreditCardInfo)
         (PayPal     Email)
         (Check      CheckNumber)
         StoreCredit
         Cash)
   

   You might construct a value with something like (Paypal (Email "string@example")), and pass along this object (which is a PaymentMethod) to a function taking a PaymentMethod and doing something to it. You would use the (match ...) syntax to handle the various cases and extract out sub-data as needed. (Note there's none for StoreCredit, it by itself is all the info you need to make a match choice. You could just as well simplify the other two options and look up data elsewhere. In another language you might use enums for this. Having data directly there can be nifty though. e.g. in a state machine with an OrderStatus that's either Unpaid, Paid, Shipped, or Cancelled, you might carry along a Reason string (or richer type) for a Cancelled status...)

   define-struct can be used to model "and" relationships, or "product types", for bags of data where all fields are meant to exist at once. e.g.

       (define-struct Widget 
         (name  String)
         (sku   String)
         (price Cents))
   

   Values are constructed like (Widget "Anvil" "1234" (Cents (* 50 100))) and individual data can be pulled out with accessors like (.name my-anvil).

   Lastly you have type classes, which can be used for polymorphism in an interfaces sense. For a contrived example you might want to write a generic calculate-total-tax function that works for either Widgets (taxable) or GiftCards (not taxable). The type signature could be: (declare calculate-total-tax ((Taxable :a) => :a * Fraction -> Cents)). That is, it takes some taxable item, and a tax-rate (being lazy with a simple Fraction), and returns a Cents value. That Taxable is a type class constraint, which you define with define-class, along with any functions that make up the complete interface, such as: (get-taxable-amount (:a -> Cents)). You then use define-instance to write a get-taxable-amount function for Widgets (returning a full price), and another for GiftCards (returning 0), and so on if another type comes along. You can also extend built-in type classes this way to support your own new types.

   Show morethread
2. BoiledCabbageApr 2026
   Buy his book - it's great and exactly like that.

   Domain Modeling Made Functional - Scott Wlaschin

   In the link above he's described 7 very practical ways to use it. No functional jargon, no mathematical jargon. Just practical useful ideas. And the language choice in the book is irrelevant - the concepts translate well.

   There is an alternate universe where he would be well known as the top author on software engineering. His website is great as well.

   That said, if you do know a bit of the math his example introduced commutative, invertible, invariance, idempotency, structural recursion & isomorphism - but anyone reading it would never really know and would never need to know. It's just framed as useful applications of tests.

   Show morethread
3. vips7LFeb 2026
   Not who you asked, but I decided to try F# after reading “Domain Modeling Made Functional” which uses F# and is one of the best books I’ve read on domain driven design. I cannot recommend it more.

   That being said, F# wasn’t really for me and applying the ideas from the book into other languages has been a better fit for me.

   thread
4. raegisJan 2026
   Maybe check out Scott Wlaschin's videos on YouTube. There is one talk for his book "Domain Modeling Made Functional" which, if I remember, was very clear and easy to follow.
   thread
5. ejflickNov 2025
   I've read his book "Domain Modeling Made Functional" without much prior knowledge of F#. He provides some compelling examples and some of it ended up inspiring how I write OO code. F# seems cool but it felt like it was close to being extinct.
   thread
6. rapnieSep 2025
   I can recommend "Domain Modeling Made Functional" by Scott Wlaschin presented at KanDDDinsky 2019, that offers a very appealing example for making making invalid states unrepresentable. The example code is in F# but that is a perfect language to demonstrate the general idea. Best-practice I guess boils down to finding the right balance throughout the application design.

   https://www.youtube.com/watch?v=2JB1_e5wZmU

   thread