I didn't get it any of the times I read it either FWIW, it just randomly clicked one day for me while coding and I connected it back to the article I'm not the

I didn't get it any of the times I read it either FWIW, it just randomly clicked one day for me while coding and I connected it back to the article I'm not the smartest tool in the shed, if I could dumb it down a little (sorry Alexis, and hopefully I'm doing you justice here!), I think it boils down to this: In many programs, you have logic like the below: function processOrderRequest(items: List<Item>, customer: Customer) { if (items.isEmpty()) { throw new IllegalArgumentException("Items cannot be empty") } if (customer.isBanned()) { throw new IllegalArgumentException("Customer is banned") } // ... orderAPI.placeOrder({ // .. final order object with some logic }) } This makes sense, but if you look at it another way, what you're trying to encode is some function like this: function processOrderRequest( items: ValidatedItemList, // A non-empty list of items we've know are okay to send customer: VettedCustomer // A customer we've vetted and know is okay to place an order ) -> PlacedOrderRequest { // ... } What this does is allow you to move the domain of validation away from the fragile business logic of your program, and into the deeply-embedded domain of your data types. It also allows you to control and refactor the validation logic much easier, since they live in your data-types and at boundary points Once I grokked this I was like, whoa. Neato idea.