[TYPO3-50-general] Last minute concept fix? Incosistent class naming for domain models ...
don at zampano.com
Wed Jun 3 22:27:01 CEST 2009
Christopher Hlubek wrote:
> At a first glance I really don't like the Model suffix for model
> classes. It's a Blog after all. The naming of properties would be no
> longer consistent (like $postModels which is awful or $posts but
> containing PostModel objects). I think it's a general rule of thumb,
> that variables should be named after the type if there is no other
> special meaning.
Is it really a *general* rule or just a best practice?
I'm not sure. Looking at some Java code here I can see
Looking at some code of my current project I read
Perhaps there is such a kind of rule somewhere, or often a type should
contain the type at least partly in the name.
But much more important is the fact that your interfaces are telling the
true story and the variables are named after which role they play.
Domain relevant "variables" should be almost always types or type-safe
even the most simple ones like Name, Date or Email (perfect for
"self-validating" value objects).
> The other classes like a repository, the validator and service are
> rarely used inside the domain model itself and are more a technical
The interfaces of Repositories are part of the domain model, but the
actual implementation depends on the storage type used, therefore is
tied to infrastructure.
And you have to distinct between two kinds of services, application and
domain. The latter are also part of the domain model.
>But I think one of the greatest achievements of DDD is the
> language part and that would be polluted by the Model suffix.
That's true, but sadly we have to live with the limits the "framework"
i.e. a language like PHP gives us.
["Don't fight the framework" - Evans.]
If some day these limitations disappear you'd only have to refactor your
stuff and everything's fine again.
More information about the TYPO3-project-5_0-general