Plainionist Journey of a Software Craftsman

Book Review: Domain Modeling Made Functional

Unless you are not completely new to our profession I am pretty sure you already heard about “Domain Driven Design” (DDD). But maybe you think that DDD requires quite some effort which is only worth it in big software projects and that it has to be done in the beginning of a project to be effective?

This is not necessarily true …

Here is a book which nicely demonstrates that DDD and Functional Programming (F#) are two great tools to tackle software complexity in any software project, even in a small pet project:

Book: Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

In this book Scott Wlaschin - the author of F# for fun and profit - does a great job to demystify DDD and Functional Programming (FP). He uses simple and practical examples and avoids any kind of complex, scientific or scary terminology. This way you can easily follow his thoughts even if you have no previous experience in DDD, FP or F#.

The book starts with a great statement:

As a developer, you may think that your job is to write code

I disagree. A developer’s job is to solve a problem through software, and coding is just one aspect of software development. Good design and communication are just as important, if not more so.

Scott then jumps right into DDD explaining the importance of a shared model, how to understand the domain through business events and the need to partition the domain into subdomains (bounded contexts). He completes his introduction by explaining the need for an “Ubiquitous Language”. By the end of the first chapter you already learned all the key aspects of DDD.

The next chapter teaches you how to learn about the domain itself which is key to ensure that your software system will finally solve the right problem in the right way.

Chapter 3, the last chapter without code, talks about the important aspects of a domain and business focused architecture. You will find similarities to “Clean Architecture” and the “Onion Architecture”.

The remaining ten chapters are very practical by focusing on how to model the domain using concepts of FP such as types and functions. Each concept is introduced step by step using simple and practical examples. To complete the journey Scott shows how to incorporate such “nasty things” as error handling and IO into a DDD focused software system.

The last chapter demonstrates that DDD works well with agile software development by showing how to “Evolving a Design and Keeping It Clean”.

Conclusion

This book is definitively on my list of “recommended readings” for senior software developers.

Tags: book