First up, congrats on getting over the hump — I struggle to complete a blog post, so I very much appreciate the effort it takes to do this!<p>A confusing sentence I noticed in the first chapter:<p>> ...then the only thing cost was some time, if they do it wrong, the cost is usually a bug.<p>I am guessing you mean "only cost was some time" (without the "thing")?<p>As for the topic, my hypothesis is slightly different — adopting functional approach to programming — even in imperative languages — leads you to the best patterns (or as you put it, "makes it inevitable") when combined with "evolutionary" architecture, and DoP is certainly one of them.<p>However, for a majority of software, in my experience, data "attributes" are really "leaf nodes", only to be consumed for display, and types do not really matter much there (eg. I don't mind `firstName` being a simple string). What we want to get right is types we do operations on, and most critically, relations between different data models. Accepting "evolutionary" principles in architecture also means that you welcome change and build for it, so getting any definition of data right from start is not an imperative.<p>But the topic certainly seems intriguing, so I look forward to learning more from your book and seeing how you apply it in a more imperative/OO way and what language features you found critical to success there.<p>Congrats again and good luck!