feat: split model and entity

[Rainrider]

First of all thank you for your amazing project and your conference talk, really appreciated.

I wanted to see how much effort it is to separate the entity from the book model and ended up with this. Could you guys provide some feedback if this is the way to go?

[andesk]

I just saw this PR and thought I'd reply. I am not part of the API Platform team at all though, as a small disclaimer :-)

Having two separate objects is one way to do it. I think I saw many people using inheritance even in such cases (InfrastructureBook extends DomainBook).
The alternative that I think you could consider is not using attributes/annotations, but moving your configuration of the doctrine entity particularities to e.g. a yml configuration. You'd have the Book entity in your Domain and "make it Infrastructure" by mapping its properties to the ORM. 90% of anything you'd want should be achievable with that approach, plus you'd avoid mapping/converting objects to each other.

The last bit (my ~10%?) which I am unsure about myself is, if you'd have the need for x-to-Many relations, for example Book->getAuthors(). As in Doctrine Entities, you aren't returning arrays of related objects, but a Doctrine ArrayCollection. So some tiny little bit of Infrastructural implementation detail would need to slip into the Domain to keep it one object only, to all I know.
Maybe someone can point to treat that even more "clean"? Sometimes a certain level of pragmatism miiiight be okay?

[Rainrider]

Thanks for your comment @andesk. This comment explains the rationale of the current implementation (using Doctrine attributes on the book model) quite well. I just tried to cover the imaginary case where the domain model diverges from the one needed for persistence. Your example with doctrine relations would fit this. The repository acts as the adapter between business domain and persistence layer here, which is ok. In this PR I keep part of the translation logic in the doctrine entity. I think this is ok, because if I were to swap Doctrine for something else I would have to replace the entity and the adapter (repository) but won't have to touch anything in the domain or the application layer.

I don't think it is pragmatic to leak infrastructure details into the domain because you risk spreading those out in the domain and you introduce coupling to infractructure which should be replaceable. Having to write the adapters is the trade-off for this.

I will close this PR as it was not meant to be merged but only a discussion base. Thank you again for your participation.