It’s easy to accept that objects should be used in all layers except a layer nominated as a data layer. However, it’s just as easy to end-up with an ‘anaemic domain model’ that is just an object representation of data with no real functionality ( http://martinfowler.com/bliki/AnemicDomainModel.html ).
However, using objects in this fashion brings the benefit of factors such as Intellisense support, strong typing, readability, discoverability, etc.
Are these factors strong arguments for an otherwise, anaemic domain model?
1
It all depends, surely, of what are your options.
You should understand that alternative to “(anemic) domain model” is not “something without strong-typing”, but “data transfer objects”. Both are strong-typed (with all included benefits), but there’s strong semantic difference between them.
2
What I understood from the article:
The programming language does not matter. So
factors such as Intellisense support, strong typing, readability, discoverability, etc.
do not matter to the authors opinion.
One problem I see is to distinct between your domain and your use-cases.
For me the domain belongs into the domain model and the use-cases into the services. But I have not much experience with large-software-developement.