[bccdee]

> However, DDD has a strong object-oriented core

The original 2003 DDD book is very 2003 in that it is mired in object orientation to the point of frequently referencing object databases¹ as a state-of-the-art storage layer.

However, the underlying ideas are not strongly married to object orientation and they fit quite nicely in a functional paradigm. In fact, ideas like the entity/value object distinction are rather functional in and of themselves, and well-suited to FCIS.

[1]: https://en.wikipedia.org/wiki/Object_database

[motorest]

> The original 2003 DDD book is very 2003 in that it is mired in object orientation to the point of frequently referencing object databases¹ as a state-of-the-art storage layer.

Irrelevant, as a) that's just your own personal and very subjective opinion, b) DDD is extensively documented as the one true way to write "good code", which means that by posting your comment you are unwittingly proving the point.

> However, the underlying ideas are not strongly married to object orientation and they fit quite nicely in a functional paradigm.

"Underlying ideas" means cherry-picking opinions that suit your fancy while ignoring those that don't.

The criticism on anemic domain models, which are elevated to the status of anti-pattern, is more than enough to reject any claim on how functional programming is compatible with DDD.

And that's perfectly fine. Not being DDD is not a flaw or a problem. It just means it's something other than DDD.

But the point that this proves is that there is no one true way of producing "good code". There is no single recipe. Anyone who makes this sort of claim is either both very naive and clueless, or is invested in enforcing personal tastes and opinions as laws of nature.

[dangets]

> "Underlying ideas" means cherry-picking opinions that suit your fancy while ignoring those that don't.

Yes, that is how terminology evolves to not meet a rigid definition that was defined in a different era of best-practice coding beliefs. I'll admit I had trouble mapping the DDD OO concepts from the original book(s) to systems I work on now, but there are more recent resources that use the spirit of DDD, Domain Separation, and Domain Modeling outside of OO contexts. You're right in that there is no single recipe - take the good ideas and practices from DDD and apply it as appropriate.

And if the response is "that's not DDD", well you're fighting uphill against others that have co-opted the buzzword as well.

- https://learn.microsoft.com/en-us/dotnet/architecture/micros... - https://www.infoq.com/news/2013/06/actor-model-ddd/

[bccdee]

> Irrelevant, as a) that's just your own personal and very subjective opinion

Yes? And it's just your personal, subjective opinion that this is irrelevant. Most meaningful judgments are subjective. Get used to it.

> DDD is extensively documented as the one true way to write "good code"

Who said this? I've seen it described as a good way to write code, and as a way of avoiding problems that can crop up in other styles. But never as the only way to write good code.

> "Underlying ideas" means cherry-picking opinions that suit your fancy while ignoring those that don't.

No it doesn't. What? The only way I can make sense of what you're saying is if you're cynical toward the very concept of analyzing ideas, which is perhaps the most anti-intellectual stance I can imagine.

> The criticism on anemic domain models [...] is more than enough to reject any claim on how functional programming is compatible with DDD.

Why would an author's criticism of a certain style of OOP make a methodology they have written about incompatible with non-OOP paradigms? That's like saying that it's impossible to make strawberry ice cream because the person who invented ice cream hates strawberries.

> But the point that this proves is that there is no one true way of producing "good code".

There's no "one true way" to build a "good bridge," but that doesn't mean bridge design is all a matter of taste. Suspension bridges can carry a lot more than beam bridges; if you want to drive 18-wheelers across a wide river, a beam bridge will collapse, while a suspension bridge will probably be "good."