Proper location for common models and utils, for multi-module maven project using spring-boot

Question

There is a multi-model maven project, with dir layout as following:

xxx-parent/
      common/
      common-web/
      member-api/
      admin-api/
      market-service/
      ...

As you can see, there is a parent pom, and multiple sub modules, the common or common-xxx modules are the commons parts, which would be dependencies of other non-common modules, for code reuse.

---

Questions

• A . Where would you put the model classes, which are usually POJO, with private fields, and getter/setters.
  These models might be reused by multiple non-common sub modules, (eg both market-service and admin-api ) .
• B . For some api, those model could be reused in the returned json, but only need part of the fields, would you create a separate POJO (usually I call it entity ) for that case? And, if so, you would probably put it in the specific sub module (eg admin-api) , not the common projects, right?
• C . If this is a spring-boot based project, and it use Redis , and we wrote a redis util, which could be reused for most redis operations.
  The problem is if we put the redis util and its maven dependencies into common, then it will connect to redis on application start automatically, but some of the sub modules don't need redis.
  The solutions I am considering are:
  • Create a separate sub module common-redis for the util.
    But there would be other utils too (eg common-jdbc ) , and there seems to be too much of common modules.
  • Disable sprint-boot's auto config for a specific feature (eg redis) via @EnableAutoConfiguration , so that, it won't try to connect to redis on start.

Answer 1

Your maven multi-module structure:

xxx-parent/
      common/
      common-web/
      member-api/
      admin-api/
      market-service/
      ...

Let me answer the questions individually.

A. Where would you put the model classes, which are usually POJO, with private fields, and getter/setters. These models might be reused by multiple non-common sub modules, (eg both market-service and admin-api).

Typically, you'll have the model classes under a separate module called xxx-entities or xxx-defs (defs stand for definitions) under your parent project xxx-parent . I'm not sure what the common module contains, but some projects use the word xxx-commons to define the common models(/POJOs/Entities). This is the module that you'd give to other modules as dependencies. Example: If you have a separate persistence layer which would want to operate on the model classes and you'd want to separate that out from your REST client library that you've written for your service.

B. For some api, those model could be reused in the returned json, but only need part of the fields, would you create a separate POJO (usually I call it entity) for that case? And, if so, you would probably put it in the specific sub module (eg admin-api), not the common projects, right?

You can reuse the same model library from my previous point. If you only need part of the fields, set only those fields (while other fields remain null) and return back. Most REST libraries have settings for serialisation which you can set to ignore null values while generating JSON from the object. Example: Ignore null from Json using Jackson.

C. If this is a spring-boot based project, and it use Redis, and we wrote a redis util, which could be reused for most redis operations. The problem is if we put the redis util and its maven dependencies into common, then it will connect to redis on application start automatically, but some of the sub modules don't need redis.

Your approach sounds right. You can have a single library something like say data-utils which can have wrappers to operations pertaining to databases (Redis, RDBMS, etc). And you can have init sort of methods which will ensure they don't load automatically unless explicitly called by their clients. Care should be taken to ensure that the configurations such as Redis hostname, port, etc should be loaded from the parent module which encompasses this data-utils client and that this library cannot have such configurations as part of it.