I just finished reading Domain Modeling Made Functional. Wow, the technique in this book just feels right. It wraps up a bunch of development values I already had in a technique that is clear, thorough, and fluid. Here I’ll overview the method and recount a bit of my experience applying it.
My deep live into functional programming has definitely made me a fan. Most importantly, it helps me see a way for programming languages to keep evolving.
Union types are common in functional languages, but have yet to make it to C# and similar. These types solve a simple and very common problem, data that is one of a finite set of possibilities. Here’s we’ll look at how to accomplish the same in C#.
Like most people, I’ve found monads hard to pin down. I know things I can do with them, but I don’t understand them at an intuitive and flexible level. Here I’ll try to build my mental model by relating to other tools.
I once worked for a company that exposed all of their entities IDs as integers. It’s common practice, but it bit them hard when they needed to adopt an offline-then-merge strategy for client data. This required switching ids to Guids all over the code base and it was an arduous undertaking. I’ve been trying and failing to simply abstract ID types since.
I want to cleanly represent predictable failure states as part of my function contracts. This lets consumers know right away what scenarios they should expect without documentation or looking through code. F# encourages this pattern and normalizes it with the Result type. Representing the same idea in C#, however, is non-trivial.
Sometimes a constructor or function can naturally accept multiple types. The classic solution to this is overloading. The problem is overloading can combinatorially expand for every multi-typed parameter.
Aspect-Oriented programming has captivated my imagination for years. C#, however, does not support AOP. Even conceptually realizing benefits of the paradigm proved difficult. Then, I experienced functional composition.
Service-Oriented Programming is my primary programming paradigm. It divides the software into self-contained “services” or groups of functionality. Services also apply in functional programming, rather, service-like behavior is enforced all the way to the foundational functional concepts.
Language is strongly related to the kinds of thoughts we have. Language shapes to favor what it’s users most want to describe. This post introduces a series about how I internalized the value of different programming languages. Specifically, my transition to functional-style thinking. I’ll be diving into concrete design problems and how FP trivialized my long-standing struggle with them.