I am in the design stage of a web application that allows users to create requests of work and the workers to put time against those requests. The application will also have reporting capabilities for supervisors to get daily totals, reports, and account for time spent, "cost allocation".
Applications I've worked on in the past have been designed using the package by layer approach. I'm thinking it would be more efficient to use a package by feature design and I have a question about this design.
What I am currently thinking for the packages by feature:
I would suggest to start package things based on business entities. And in there you can divide things based on layers.
With all of the overlap is this really functional?
I am practising it for long. I don't see any major issues with this approach. You must find out what to decouple and how much it should be decoupled. For example, calling a persistent method of
orders from a
customer package using the API provided by
orders is pretty fine for me.
What are the pros and cons to using package by feature?
I find it more simple, straight, understandable and easy to work with than strict layer oriented packaging. It benefits when you want to split and distribute things to different places.
Would it be good design to go with an additional persistence layer?
Look at this SO thread, I found JPA, or alike, don't encourage DAO pattern.