[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
anyway,
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.
Cheers!
More information about the TYPO3-project-5_0-general
mailing list