Domain Modeling Made Functional : Pragmatic Programmers

This is a very good book. It delivers what it promises.If you want to go "functional", if you want to learn F# - this is the book for you. You won't find better.By the way, why you want to "go functional"? To write a better code? You don't have to go all-functional for that. And even if you want to go functional, why F#? why not Haskell? Why not Scala?Questions such as "Why you want to go functional?" are completely outside of the scope of the book. Which is, again, as promised.Let's say you want to "go functional" because you don't know how to solve the persistence problem with the OOP (object-oriented-paradigm). It's a very good concern and very good thinking of yours. Because the data persistence is the actual problem. The fact, which author of the book might not be aware of.He advises to "push persistence to the boundaries of the DDD (domain-driven-design) model". And this is a very good advice, very solid advice. I agree with that 100%.Still, DDD, in my humble opinion, is actually called to solve the persistence problem, not some other unknown or implicit problem.You can create a very good data model in any programming language using any programming paradigm if you don't worry about data persistence. But in case you are not aware that the problem exists, why F#? Why functional?

Premettendo che ho sempre programmato ad oggetti e neofita sul DDD, ho trovato il libro molto chiaro, non solo per gli esempi fatti, di facile comprensione, anche per chi non ha mai usato F#, ma anche per come viene trattato l'argomento DDD.

El libro está muy bien escrito. Es ameno de leer. El escritor ha hecho un gran trabajo clarificando los conceptos para que sean fáciles de digerir.En la primera parte explica qué es el Domain-Driven Design y qué beneficios tiene aplicarlo.En la segunda parte entra más en detalle en el tema y explica cómo modelar la aplicación de ejemplo en F#. Yo no conocía F# antes de comprar el libro pero la puesta en escena del lenguaje es tan clara que me llevo un gran sabor de boca de lo interesante que sería programar en él. Reitero lo increíblemente bien que se explica este hombre.Ya en la tercera parte, se adentra en el código razonando los porqués de la estructuración bajo el paradigma funcional.Personalmente, compré el libro recomendado por un experto en FP y tenía razón al decir que la exposición de cómo estructurar un programa funcional es muy clara en este libro. Además, de regalo te llevas el conocer DDD.

Das Buch eignet sich gut um in die funktionale Programmierung einzusteigen bzw. sich fortzubilden; für mich als Java-Entwickler war es sehr hilfreich zu sehen wie man Probleme zerlegt und organisiert, wenn man nicht mehr objekt-orientiert arbeiten kann (z.B. ohne Seiteneffekte) und daher anders (und IMHO besser) vorgehen muss; er ist einer der wenigen, die ein (für viele OO-Programmierer ganz neues) Thema wirklich verständlich präsentieren kann.Man kann sich Scott Wlaschin und seinen Lehrstil auf Youtube ansehen um einen ersten Eindruck zu verschaffen.

As a C# programmer, I get very annoyed by the number of "Why use F#?" and "F# vs C#" articles I see that attempt to sell F# by belittling C#, usually incorrectly. The (very) few convincing articles are usually demonstrating trivial tasks that aren't really challenges in either language. I spent a long time totally unconvinced as to the benefits of F#, until I decided to ignore those articles and just try learning it anyway.This book is a game changer. Apart from a very clear explanation of DDD[*], the way he explains the evolution of the types, and the simple translation of the simple language that the domain expert(s) can understand into F# is very powerful. You can see how the code itself becomes the documentation. Whilst I don't see curly braces and "get; set;" in C# as noise (my mind filters them out), I can see how a non-developer would struggle to make sense of a C# class, whereas the F# type is so clear that any non-developer could understand it. The domain model can evolve with the code, documenting itself as it goes along.As for the idea of functional programming vs imperative programming, I'm still not convinced that either has a huge advantage over the other. C# has so many functional features that the lines are becoming increasingly blurred. However, the way he demonstrates splitting the workflow into sections, and piping the output of one into the next is very clear and clean, and his use of section-specific types means you can't really get it wrong. I can see how this approach to coding could drastically reduce the number of bugs. It does lead to a type explosion, but it's probably worth the price, given how simple the types are in the first place. Again, this isn't anything you couldn't do in C#, but it looks a lot cleaner in F#.If you're still looking to be convinced about F#, you should certainly read this book. Even if you aren't, it's probably still worth reading, as the explanation of DDD is excellent[*], and what he says can be applied to C# as well.[*] Caveat, I haven't read any other books on DDD, so can only comment on how I found this one, not how it compares with any others