Ask questions and see you at December, 7th, 8.PM. CET: https://vimeo.com/event/154379
Also checkout recent episode:
Please keep the questions Jakarta EE-stic. Means: as short and as concise as only possible. Feel free to ask several, shorter questions. Upcoming airhacks.tv events are also going to be announced at meetup.com/airhacks
How to keep the service (boundary + control) layer DRY in an application with hundreds of entities? In your demos I typically see a REST resource & corresponding "Manager" on a 1:1 with an entity (at least a DDD "aggregate"). One way to address this could be to create a universal "Manager" using generics (including some cross cutting concerns like security) and inject it into a generic REST endpoint. The latter could then be subclassed with specific Entity type (and a corresponding URL path). I think I picked up in one of your talks (or workshops - can't remember) that you don't typically see inheritance used in the business code outside of maybe JPA entities. So are there any alternatives? Writing 100+ Managers and Resources gets old fast… Is it OK to introduce some inheritance - maybe at least for master data?
I was thinking of using some variations of the Gateway pattern from your green book but that seems difficult due to stateless nature of REST (and not quite ready to directly expose the Entity Manager to a javascript web client).