My idea is to create DTO object instead (http://ocramius.github.io/doctrine-best-practices/#/57) and then use named constructors to create entities. I want to call named constructor inside my service. What is the best way to force admin panel generators to use my DTOs to persist/update data, can you give me an idea and/or example of good practices in that case?
The only way I imagined is to use DTO instead of real Entity, call prePersist/preUpdate hooks and use custom service, but it looks confusing.
One of the most important aspect of DDD is to correctly identify your bounded contexts (usually aligned with your sub-domains) and determine the appropriate technologies and architectures to use within those.
An admin panel sounds like something generic that would be very CRUD in nature. If that's the case then don't try to fight it and embrace CRUD within that BC. Trying to implement a pure domain model in a BC where it isn't needed would make things more complicated than they need to be.
However, if you determined that the complexity justifies a domain model then I would advise against using a code generator. Properly modeling the reality of a complex domain is not an easy task, and certainly not one that could be achieved by a tool.
Asked in February 2016Viewed 1,911 timesVoted 11Answered 1 times