4 ms·
You hit the nail on the head. Objects in OO shouldn't be a projection of the problem domain, they're a way to structure the program (there's some overlap, of co
by adwn 12y ago
You hit the nail on the head. Objects in OO shouldn't be a projection of the problem domain, they're a way to structure the program (there's some overlap, of course).
Many people seem to get this wrong, probably in part due to introductory examples doing it wrong.
- platz 12y agoI suppose you disagree with Eric Evans method of Domain Driven Design (DDD - http://domainlanguage.com/ http://domainlanguage.com/) Don't people who practice DDD, including Martin Fowler, commonly talk about the benefits of some of it's concepts, while modeling the Domain using Aggregrate Roots, Bounded Contexts, etc?
- huherto 12y agoMartin Folwer talks about several approaches for handling domain logic. Transaction Script, Domain Model, Table Module, and Service Logic. He explains the trade offs of each on the Patterns of Enterprise Application Architecture book.
- platz 12y agoSince then he has also written a lot more as well, for example http://martinfowler.com/tags/domain%20driven%20design.html http://martinfowler.com/tags/domain%20driven%20design.html . While less a direct connection, folks who use DDD a lot also find CQRS (command query responsibility separation) a natural fit and are often seen being used together.
- huherto 12y agoYeah, that makes sense. It simplifies both.