3

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.

2
  • 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, 2018 at 17:43
  • I would say both. Oct 7, 2018 at 19:17

1 Answer 1

4

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.

2
  • Would you add files in the feature folder reexporting the original shared library to make it clear ?
    – Ced
    Aug 8, 2022 at 13:57
  • @Ced: different programming language ecosystems have different conventions of documenting or implementing library dependencies from the technical perspective. My answer tries to stay mostly language/ecosystem agnostic.
    – Doc Brown
    Aug 8, 2022 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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