@heiglandreas I've had troubles trying to convince for what you advocate. PHP world seems to have this notion of dev deps so embedded and tightly coupled to the production code..
For a slightly higher level perspective, personally I have found inspiration and therefore I recommend, to take a look at Ivar Jacobson ideas, which mainly include as users/actors of the "system" (whole) the developers which develop the system. There are use cases that the system must cover for them to do their job.
Also to mention the notion of a "toolchain". There is some effort I have seen here https://github.com/pronskiy/phpup although I am not sure of how this goes (I do not follow up much).
In general the notion of a toolchain, like in other ecosystems (possibly rust? or golang) is in a way missing from PHP.
And last, a question, if you do not use multiple composer installations for your tools but a single one, what can go wrong? :) I mean.. I can endure my tools to be limiting to each other
If you were about to start a medium-sized #PHP project, what would you choose as an #ORM, and why? It should be something stable and well maintained. If the business takes off, then there should be no need to replace that layer.
Caveat: imagine that Doctrine and Eloquent haven't been invented yet.
@oliver Nevertheless, if you structure it well AND that layer becomes a burden in the future for whatever reason, because it is structured well you will be able to replace it easily.
In reference to hexagonal / layered architectures.
@oliver I mean.. the way you put it, the data mapper is only convenience probably. I think valinor supports stuff like nested levels that ocramius/GeneratedHydrator doesn't for example. Not sure 100% for either.
Personally, I would not consider writing my own data mapper, just for the sake of not losing time with the project.
Recently, I favour the notion of "first version is probably throw-away code" and just try to make it work. It all depends on what level you design things, I guess..