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.

Improve this question
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) ? Commented Oct 7, 2018 at 17:43
  • I would say both. Commented Oct 7, 2018 at 19:17

1 Answer 1

Reset to default
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.

Improve this answer
2
  • Would you add files in the feature folder reexporting the original shared library to make it clear ? Commented 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. Commented Aug 8, 2022 at 15:04

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.