Just finished reading "Functional Design and Architecture" by @graninas. As promised, my book review. TL;DR It's a good book. But it's not for everyone. First of all, the target audience is crucial for the book. If you're an author, it's important to understand your audience. If you're a reader, it's important to know whether you're in the target audience to benefit from reading. I had the impression that this book's target audience consists of Software Engineers who know FP and even Haskell but are not satisfied with popular design approaches and want to get inspiration from mainstream practices. I don't think there is a huge number of such people; Haskellers are usually inward-looking. But if you're one of them, you're quite open-minded, and you'll benefit from this book a lot. Another challenge of this book: I feel like it covers diverse topics. I can imagine at least several books written in detail about themes mentioned in this book: 1. Making diagrams for sharing your thought process and architecture 2. A Haskell tutorial 3. A Free Monad tutorial 4. A DDD tutorial 5. Comparison of FP approaches 6. Testing in the FP world 7. Concurrency tutorial 8. Importance of the Systems Design 9. Hierarchical Free Monads and FDD This is a good thing! It means that value for money is great, and you can learn about many topics from one book. But at the same time, this book can't afford to cover every single topic in detail. You have to have some knowledge about them and be on board with the main ideas to understand their value. The author respects the reader. There's little jargon. There's no gatekeeping. Trivial things are not explained. Yet complex things are elaborated. While food for thought is left to the reader. This book is like a text RPG quest: you're given directions to complete your task but you have to do the rest of the work on your own. I liked the first example about designing the scripting language for a spaceship system. It's not a boring example, and you can easily see how real-life software can get complicated. Even this highly simplified demo example in the book is already quite difficult to implement. I especially liked the part about Software Transactional Memory (STM). The book did a great job explaining how systems can instantly skyrocket in complexity once you add a tiny requirement e.g. logging inside a transaction. Alexander presents the approach with Hierarchical Free Monads. But you can clearly see that the author is not trying to push this approach for every single use case. There's a comparison between Handle, ReaderT, Final Tagless and Free Monadic patterns and the Free Monad's one is not the best choice for the task in question. My verdict: if you really want to level up your systems design skills and learn some FP approaches, it's a good book to read. But please, read a Haskell tutorial first. ----- As a side note, reading this book made me reflect on the complexity of modern software. While reading, I kept thinking "Is this complexity really justified? Is FP really good?" For context, just to implement a Web Backend framework based on Free Monads, I noticed that the following Haskell features were used: Algebraic Data Types Typeclasses Monads Higher-Order Functions Higher-Kinded Types MultiParamTypeClasses GADTs FunctionalDependencies TypeApplications AllowAmbigousTypes TypeFamilies Rank2Types I know all these features. And their usage makes sense. But I tried putting myself into the shoes of the person who doesn't know anything about FP. And in those shoes, it's really hard to see whether learning these 10 FP features is superior to learning 10 OOP patterns. No matter what you think, software can be really complex. This book demonstrates this well. And if language features or design patterns can really help with simplifying them, why not use them? But the learning journey takes a while. You can't become an expert instantly.