Microservices and maven structure

Matheus78 0
Viewed 43

I'm really confused how someone would build some micro-services with Maven. I've seen a lot of project using the multi-module strategy

  1. Is that a valid strategy? wouldn't that couple the whole project? because I will need to build the project from root (parent pom.xml)? and everything is related to everything I think

  2. Should I just build everything in their own?

    • firstapplication

    • seconddapplication

    • thirdapplication

Any help is really appreciated.

I'm really lost on how this works

[ parentpom.xml ]
|
|___first-application
|   |
|   |__ data-layer
|   |   |__ pom.xml
|   |   
|   |__ services
|   |   |__ [[ USES message-queue:producer ]]
|   |   |
|   |   |__ pom.xml
|   |   
|   |__ domain
|   |   |__ pom.xml
|   |
|   |__ application (REST)
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|   
|___second-application
|   |
|   |__ data-layer
|   |   |__ pom.xml
|   |
|   |__ services
|   |   |__ pom.xml
|   |
|   |__ domain
|   |   |__ pom.xml
|   |
|   |__ application (REST)
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|
|___third-application
|   |
|   |__ data-layer
|   |   |__ pom.xml
|   |
|   |__ services
|   |   |__ [[ USES message-queue:consumer ]]
|   |   |
|   |   |__ pom.xml
|   |
|   |__ domain
|   |   |__ pom.xml
|   |
|   |__ application (REST)
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|
|
|___message-queue (as wrapper of kafka/rabbit/etc)
|   |
|   |__ configuration_of_message_queue
|   |   |__ pom.xml
|   |
|   |__ consumer
|   |   |
|   |   |__ [[ USES message:queue:configuration ]]
|   |   |
|   |   |
|   |   |__ pom.xml
|   |
|   |__ producer
|   |   |
|   |   |__ [[ USES message:queue:configuration ]]
|   |   |
|   |   |
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|
|
|___ commonlibrary (some projects use this, some others dont)
    |__ pom.xml

<parentpom>
  <modules>
    <module>first</module>
    <module>second</module>
    <module>third</module>
    <module>message-queue</module>
    <module>commonlibrary</module>
  </modules>
</parentpom>
maven spring microservices spring-boot java
1 Answers

What you are signalling is at if monorepo is a good strategy or multi- repo (repo per service/library).

Note:

Each independent repo or same repo can be itself multimodule project itself.

There is already a huge debate on mono vs multi repo.

Both are good fit for microservices.

Lots of things become influencing factor for this decision.

  1. How are you going to write devops pipelines.
  2. how you want to structure your builds.
  3. Team requirements - is it okay for multiple teams/members committing in same repo for per microservice/team structure.

If you are going for monorepo(single repository all microservices+ libs)

  1. You see all code at one place.
  2. Easy to collaborate as codebase is same.
  3. Easy to build and fix if any issues as its single codebase
  4. Easy to control build lifecycle - ie libs will be built in order first then microservices.
  5. Sometimes you will run in conflicts and issues if multiple teams are committing in same codebase.
  6. However, all teammates must follow some standards, practices and guidlines when many people are working on same repo. It is very essential to have proper procedure for commit, build and release.

If you are going for multi repo(repository per ms and libs)

  1. You need to ensure you build separate project with dependencies in order you want.
  2. Build pipelines will be configured separately and cross dependencies will be there.
  3. You will have additional overhead to maintain separate projects.
  4. Debugging can be little difficult sometimes.
  5. Teams/members will collaborate and have responsibility to maintain their own repository. If that repo breaks, that repo and its build breaks.
  6. You need to ensure you publish your dependencies first and build them then work on your microservices.
  7. Its good if you have enough bandwidth to maintain multiple repositories.

Essentially both are good approaches depending on your team structure, maturity and model that you feel comfortable.

I am following monorepo for our services, following is the structure.

├── README.md
├── db
│   └── create-dbs.sh
├── docker-compose.yaml
├── docs
│   ├── 1. Prerequisites.md
│   ├── 2. Documentation.md
│   ├── 3. Running services.md
├── pom.xml
├── services
│   ├── books-service
│   └── products-service
├── shared
│   ├── archunit-tests
│   ├── auditing-utils
│   ├── project-bom
│   ├── event-publisher
│   ├── logging-utils
│   ├── rest-clients
│   └── utils
└── templates
    └── azure-template

Few recommendations for you:

  1. You can have a bill of materials for all services(bom) in libraries.
  2. You can have separate folder for services, libraries, documentation and so on.
  3. The parent pom can build whole project with libraries first then services.
  4. All folders need not be maven project, can be just simple folders.
swapyonubuntu0
Related