Cross-cutting concerns in package-by-feature structure

Question

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.

Answer 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.