Comment by lmm
9 months ago
> Domain models are fundamentally an object-oriented programming concept.
They are not.
> You model the business domain with classes, meaning you specify in them the behavior that reflects your business domain.
I have better tools for doing that.
> In Domain-Driven design, with its basis on OO, you implement these operations at the class level, because your classes model the business domain and implement business rules.
You're still not explaining the "why". You're just repeating a bunch of dogma.
> a domain model without behavior means you are wasting all development effort building up a structure that does nothing and adds none of the benefits, and thus represents wasted effort.
I know from experience that this is completely false.
> You don't know what you're doing, and somehow you're calling it Domain-Driven design.
I don't call it domain-driven. You can call it domain-driven if you want, or not if you don't want. I don't care what it's called, I care whether it results in effective, maintainable software with low defect rates.
> I care whether it results in effective, maintainable software with low defect rates.
This is what it is about. All the other things that have been invented need to be in service of this goal.
> I have better tools for doing that.
For example?
I would assume he meant to use the typesystem of his PL.