OK Smart Guy, Why Should I Read This?
I'm going to show you a few techniques that will reduce the amount of unit tests you have to write, how you can leverage your compiler to "prove" aspects of your domain rather than wait for runtime validation, make your code easier to read and reason about, and increase refactoring safety and speed as requirements change. This is a practical guide. We're going to do our best to avoid diving into theory.
Very Brief Background
ML style languages such as F# and Haskell (more commonly known as "functional programming" languages) have for many years enjoyed a set of features that makes them particularly useful for tasks such as compiler writing, automated theorem proving, and formal verification. The same qualities that make ML languages good at modeling abstract formal systems (logic, grammars, proofs) also make them good at modeling messy real-world systems (business rules, workflows, contracts). Both of these problem domains benefits from precision, explicitness, and guaranteed invariants.
Many of the features that define ML languages are making their way into more traditional object-oriented languages, rendering those languages true OO/FP language hybrids.
How Does Kotlin stack up?
While Kotlin doesn't all the features of ML languages, we have enough of them that we can get about 90% of the way towards our goal. If you adopt a small set of Kotlin FP conventions, you’ll capture the same essence that makes ML languages great for compilers/theorem provers: precise representations and trusted invariants. You won’t get all the static guarantees an ML or dependently typed language can offer, but for business domains Kotlin + Arrow (the definitive FP library for Kotlin) delivers a sweet spot of rigor, ergonomics, and platform reach.
Kotlin 2.4 will bring us even closer
https://itnext.io/rich-errors-in-kotlin-2-4-say-goodbye-to-boring-try-catch-or-not-quite-yet-24ec3192a061
Rather than list all the kotlin features that will leverage, I created a cheatsheet of features to reach for when following the recommendations outlined here: https://github.com/edreyer/safe-domain/blob/main/docs/Kotlin-ML-style-cheatsheet.pdf
What Do We Mean By Unrepresentable?
By “unrepresentable” we mean that the type system literally makes it impossible to express an invalid state in code — the compiler won’t let you construct or pass around values that violate your domain rules, so errors that would otherwise show up at runtime can’t even be constructed.