[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