[TYPO3-50-general] Last minute concept fix? Incosistent class naming for domain models ...

Nino Martincevic 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

Location from
Location to
Date arrivalDeadline
HandlingEvent event
[String name]

Looking at some code of my current project I read

IPerson $responsiblePerson
TimePoint $registeredAt
TimeInterval $closingPeriod
IAddress $requiredAddress
IAddress $optionalAddress

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
> thing. 

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 mailing list