0

What is your suggestion on where to put cross-cutting concerns in a package-by-feature structured app? This aspect seem to be missing from most of the pro package-by-feature articles I have read.

Consider for example a Java REST api:

com.myapp.authentication
    AuthenticationResource.java
    Token.java
    TokenDao.java
    ...
com.myapp.article
    ArticleResource.java
    Article.java
    ArticleDao.java
   ...
com.myapp.util
    Security.java (hash, random string, etc...)
    ...

Now, where would you put the global User object and DAO (used by most features after authentication), and the DB connection used by the DAOs?

And how would you handle cross-dao transactions?

I was thinking maybe have a startTransaction and endTransaction method on each DAO, and rely on nested transacions. Thoughts?

Another option could be to have a global DaoManager from which the service layer would request writeable/readable DAOs from, and then commit the result when done. In which case, where to put such a class? Thoughts?

I feel like this is such a common starting point for most apps I am making, which also gets me stuck so quickly.

  • Is your question about the packaging (where to put some classes that could be called from other places) ? Or is it about architecture (who should know about the classes and call them) ? – Christophe Oct 7 '18 at 17:43
  • I would say both. – user2725580 Oct 7 '18 at 19:17
1

Common code which is going to be shared between packages should be located in a package of its own. Even if your application is mainly structured by features, you have typically additional packages for the common infrastructure, or shared data objects, which cannot clearly be assigned to one feature, that is nothing really special.

Simply do not mistake the guideline "structure by package" for a law.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.