1

I built an app in the way that one context is closed in one package. However, as code grows there are more situations in which the code is duplicated. As I understand the package should contain everything that is needed for the given feature within its context. On the other hand, the dependencies between packages make code harder to follow and break those borders.

Let's imagine the situation in that I have a user package and a film package.

├───film
│       FilmEndpoint
│       FilmRepo
│       FilmService
│       FilmRequest
│       FilmResponse
│
└───user
        FilmRepo
        UsersRequest
        UsersResponse
        UserEndpoint
        UserService

And I have 3 cases:

  • The mechanism of finding a particular user is the same as for finding a particular film. Should I remove UserRequest and FilmRequest and put it in a separate package?
  • User response contains information about his favorite book. The book titles has to be censored - requirement. So this censorship is made in FilmService and UserService. Where should implementation be placed? Should it be duplicated?
  • Part of the repository entities are similar for the user package and film package, should I put it to some common entities?

The question is: where should those common parts be placed? What is your rule?

2
  • Just for some context - you're talking about two in-process modules that share the same database and are maintained by the same dev team, correct? Commented Aug 29, 2023 at 7:10
  • 1
    This is one module (one deployable jar) which hosts many paths. So Film and User are packages within this one module. This module uses one db and is maintained by the same dev team.
    – MyWay
    Commented Aug 29, 2023 at 10:09

1 Answer 1

1

Creating a dedicated package for the cross-feature code is a good practical solution. A name such as common or shared usually gets the idea across.

If a part of this cross-feature code starts to grow, e.g., if the censorship code expands so that it has several classes, you could consider moving it into a separate "sub-package" such as common.censorship.

It's not necessarily a problem for code to depend on a different package; it's usually better than duplicating things, at least. Just take care to do it sensibly with low coupling and high cohesion (e.g., if two packages each depend on each other, creating a circular dependency, that would be a code smell).


Note I would usually add a prefix to all packages following the reverse domain name convention to keep this app's code separate in case it ever needs to integrate with other code. For example, com.mydomain.fooapp.film and com.mydomain.fooapp.common.

Your Answer

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

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