[TYPO3-50-general] RFC: Short filenames

Nino Martincevic don at zampano.com
Wed Jan 28 10:50:43 CET 2009


Hi Robert.

Robert Lemke wrote:
> Domain-Driven Design is, in fact, a set of conventions itself. The whole 
> concept
> of Entities, Value Objects, Aggregates, Repositories, Services etc. is 
> based
> on conventions.

No.
There is no convention in DDD that says "Name your GroceryShop 
GroceryShopEntity or treat it like an AggregateRoot and use a 
CustomerWelcomeService".
Without a concrete domain context they are nothing. Words. Bubbles. 
Names. Buzzwords.

Those "conventions" you are listing above are not something like design 
patterns or real conventions, but they are concepts.
They only say how you should see and treat things not how you must use 
them and what the consquences are if you ignore the facts.

E.g. an ENTITY in DDD is described by Evans as:
"An object defined primarily by its identity"
and a VALUE OBJECT
"A Value Object is an object that describes some characteristic or 
attribute but carries no concept of identity."

It's important to see what that means. Not how it's called and also not 
how you design it later in your application.
It's not a technical declaration it's a logical one.
And just to be able to talk to each other Evans gave the concepts names, 
an abstraction for what they are and why they are.

For me, you are a person called "Robert" and with the role "Developer of 
Flow3". Nothing more then a Value Object, hehe.
Do you see it that way, too or do you think you are an ENTITY?
;-)

The declaration "An object defined primarily by its identity" even works 
in other programming languages, without OOP, different contexts etc. 
Because it is a concept.
And they have names to know of what concept you are talking about, but 
that only works when we are in a *developer context*.

> post a job offer to some portal stating that you need a developer with PHP,
> DDD and FLOW3 skills. If FLOW3 wouldn't offer conventions, the latter 
> requirement
> wouldn't be of any use because everybody would be using FLOW3 so 
> differently
> that it would require big efforts to get familiar with the code.

But all I said up to this point does not work against this assertion.
The conventions I talk about are not "call your file xyz or abc" but 
call it that *EVERYONE* understands what they mean for this *CONTEXT*!

You, as one Flow3 developer have set conventions for using Flow3 
together with another developers and for the consumers of the framework. 
You set the context where your conventions work.

And if I use Flow3 as a framework I should follow its conventions to 
make my life easier. But only to use it as a framework.
I also follow the conventions of MySQL, because that's the database I 
use - but with a ORM/datamapper inbetween, always exchangable.
I follow the conventions of PEAR, because that's the library I use (not 
really) but with my own adapters inbetween. If I change the i18n library 
it will work.

But, big big BUT: my real (core) domain follows the conventions my 
experts, clients, business and me and all my developers *speak* and 
understand.
I don't talk to my client and say "ah, we should adjust the 
RepositoryManager to be able to deliver the goods"...
My client would say "What the F..."?
The language we speek is the code. How could I do this if I follow the 
conventions of Flow3, ZF, Symfony or another framework?


Cheers,
Nino




More information about the TYPO3-project-5_0-general mailing list