There is a quote I saw somewhere, forget where, but it was basically: define your data structure and the algorithms will reveal themselves.
There is a quote I saw somewhere, forget where, but it was basically: define your data structure and the algorithms will reveal themselves.
That is aligned with the basic premise of Domain-Driven design: define a model of the problem domain, and everything else just falls in place.
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.
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.
Not even wrong.
""Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.""
(Though from your description I suspect that's also not the one?)
> Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious. That was in 1975. Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language: Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.