Domain Modeling Made Functional

I really enjoyed reading Domain Modeling Made Functional, an excellent intro to modeling and implementing software requirements using a functional language (F#) with Domain Driven Design (DDD) principles.

I don’t use F# (but appreciate functional programming in general) and the reason why I picked this book up is to learn and revisit DDD concepts.

The first two chapters of the book were the most valuable. The main takeaway: when doing DDD, start with the events and not domain objects! I know that when I approach a problem, I always start with trying to define the domain objects. This seemingly small switch to focus on events instead felt profound as I was reading the first few chapters.

The biggest value that software gives to its users is not in the domain objects it stores and retrieves, but in the transformation of the input data through the domain, usually via workflows which are triggered by … events! Identifying the events will give you a good idea of possible workflows that either exist or will need to exist which then lead to defining commands, bounded context, domain objects, aggregates, etc. It all starts with events.

The process of identifying the events occurs during the eventstorming sessions (a good intro here). Eventstorming unites implementers and business users together as they work on defining the events, commands, and bounded contexts. Pulling people together during this phase is a great way to make sure that as little as possible gets lost in translation when somebody takes the requirements and then “translates” them to the implementation group. Instead, implementers are active participants that learn and define things together with the users.

A domain event is the starting point, always termed in the past as it has occurred and cannot be changed. Eg. user created, user added, etc. Events can start workflows which then end with usually another event that other contexts can subscribe to and act upon.

And then the rest of the book was more around F# approach to design and implementation. Several rules stand out, such as: avoid names and concepts that are not directly described by domain experts;  build the smallest units, functions, that do the work, connect the functions to form services. Connect the services as pipelines to form workflows.

Really neat book. Even if you don’t use F#, this books introduces many great concepts and if you don’t dabble much in DDD space, gives you topics about DDD that you can then go and explore on your own.

Leave a Reply

Your email address will not be published. Required fields are marked *