Just finished reading "Domain Modelling Made Functional" by @ScottWlaschin. As promised, my full review of the book. If I can recommend one book about understanding how to model real-world problems with Functional Programming, it'll be this book. If you want to kill two rabbits with one shot: learn FP and Domain-Driven Design (DDD) - just read this book. If you want to learn F# - just read this book. If you want to learn FP architecture - you guessed it right - just read this book. I love how the book is structured around a single real-world project example and it covers lots of different problems: 1. Communicating tech design to non-tech people 2. Modeling the domain 3. Modelling external dependencies 4. Testing 5. Error handling 6. Evolving the design 7. Talking to 3rd parties 8. Talking to the database 9. Data persistence 10. Serialisation vs Persistence 11. And so much more! What's even more interesting is how it's all connected to functional programming. Honestly, if after this book you're not convinced that FP is awesome for writing enterprise software, I'm not sure you've actually read the book. The book uses F# but it looks almost exactly like OCaml, so I didn't have troubles reading the code at all. Honestly, I don't think anyone would have troubles because the book also gently introduces all F# concepts along the way, so I consider it a very accessible intro. I'm not a fan of particular approaches introduced in the book. Like the usage of Higher-Order Functions for Inversion of Control to achieve mocking for the easier tests. I hate mocks and prefer another way. But in the context of this book it makes sense, and the way it was introduced, I don't hate it too much. However, I specifically want to highlight attention to detail and countless examples. When writing real-world software, Software Engineers always consider alternatives and trade-offs. Besides, the system's design is not static, new requirements constantly arrive. So I really like how this book often considers potential changes to the design and addresses corresponding changes to the code. I want to end at the start of the book. One of the strongest book intros I've seen. Scott immediately starts with hard facts, so you don't have illusions about what Software Engineers actually do. 10/10, I recommend it to everyone.