Package structure best practices?
-
What is the best way to structure the naming of your (java) packages? By design paradigm: my.app.dao, my.app.services, my.app.util, my.app.model, etc. or by function/context name: my.app.clients, my.app.registration, my.app.production, my.app.accountancy? On a side note: I think I remember watching a keynote speech on the Spring framework where a developer advocated the structuring of packages according to the application's domain functions. The same would happen for URLs: /login /register /products/sales /products/production /accountancy/general-ledger /accountancy/analysis The problem of the classic paradigm package structure would be redundancy/visibility problems: services/userregistration services/agenda services/products model/userregistration model/agenda model/products dao/userregistration dao/agenda dao/products Each function is repeated per layer. What is the best approach?
-
What is the best way to structure the naming of your (java) packages? By design paradigm: my.app.dao, my.app.services, my.app.util, my.app.model, etc. or by function/context name: my.app.clients, my.app.registration, my.app.production, my.app.accountancy? On a side note: I think I remember watching a keynote speech on the Spring framework where a developer advocated the structuring of packages according to the application's domain functions. The same would happen for URLs: /login /register /products/sales /products/production /accountancy/general-ledger /accountancy/analysis The problem of the classic paradigm package structure would be redundancy/visibility problems: services/userregistration services/agenda services/products model/userregistration model/agenda model/products dao/userregistration dao/agenda dao/products Each function is repeated per layer. What is the best approach?
Not exactly sure what you are suggesting but if your 'services/userregistration' is based on authorization/authentication then you have a rest call for that and nothing else. Presuming that the functionality is in fact the same. That is similar to your other areas in that either something like 'products' is different for 'model' and 'services' or it is the same. If the same then there would be a root 'product' and not the way you broke it out. If they are different then they should have two different rest methods.
-
What is the best way to structure the naming of your (java) packages? By design paradigm: my.app.dao, my.app.services, my.app.util, my.app.model, etc. or by function/context name: my.app.clients, my.app.registration, my.app.production, my.app.accountancy? On a side note: I think I remember watching a keynote speech on the Spring framework where a developer advocated the structuring of packages according to the application's domain functions. The same would happen for URLs: /login /register /products/sales /products/production /accountancy/general-ledger /accountancy/analysis The problem of the classic paradigm package structure would be redundancy/visibility problems: services/userregistration services/agenda services/products model/userregistration model/agenda model/products dao/userregistration dao/agenda dao/products Each function is repeated per layer. What is the best approach?