> I wonder why these articles reinvent the wheel with functional programming hand-waving when DDD has been screaming this for years.
These are two different levels of abstraction. If you're still enraptured by the fundamental mechanisms of computation (i.e. functional programming) you're not going to see the value in trying to figure out the best way to build via composing mechanisms of computation, whether it's functional, imperative, procedural, logic-based, lisp-based, object-oriented, message-passing, whatever. There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails.
I don't see why this is surprising; people re-discover old lessons daily, and petty details will always be conflated with broader themes and patterns—it's just how the human brain works. The discussion is what keeps us thinking about those old lessons. This is just a person's blog, not a journal trying to represent an industry.
> There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails.
I think your comment fits the "not even wrong" category. It goes beyond nonsense.
There is no DDD framework because the very idea of a DDD framework makes absolutely no sense at all. DDD is an approach to software design, not something you build and reuse.
DDD is then used to specify what types to define to put together a model of the domain. Again, there is absolutely no point to have a framework to define these.
Lastly, DDD defines interfaces for domain services, and imposed absolutely no restrictions on how to define those. This has nothing to do with frameworks.
Development speed is also irrelevant and unrealistic.
These are two different levels of abstraction. If you're still enraptured by the fundamental mechanisms of computation (i.e. functional programming) you're not going to see the value in trying to figure out the best way to build via composing mechanisms of computation, whether it's functional, imperative, procedural, logic-based, lisp-based, object-oriented, message-passing, whatever. There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails.
I don't see why this is surprising; people re-discover old lessons daily, and petty details will always be conflated with broader themes and patterns—it's just how the human brain works. The discussion is what keeps us thinking about those old lessons. This is just a person's blog, not a journal trying to represent an industry.