1

We are developing two projects with two different teams. However, there are some common points in the two projects, for example, there are common entities and repository usage cases. How can I manage with a single entity/repository in two projects without code multiplexing?

Note: First project is spring-batch/spring cloud task Second project is microservices project

Thanks...

1 Answers1

5

Logically sharing DB is not recommended in most cases, due to the two teams will depend on eachother to evolve the schema, they will not be autonomous, so in practice you may end up with a distributed monolith. You may find reading about event-driven architectures useful if you go microservices.

If you really need to use the same database without "code duplication" from 2 services, and you use the same tech stack, you can create a shared lib with the repository/entities and other common parts of the system. Just treat this lib as any other 3rd party lib, this mindset helped us architecting our microservices.

But: "code duplication" is not bad if you have multiple autonomous teams. If you consider the DB schema as some kind of contract, and only one team owns it, then other teams can develop their own APIs (repositories, entities) accessing this schema, with their preferred tools/tech stack, etc... I would not even consider this code duplication.

Another idea is to create an API layer above the DB (a 3rd microservice maybe?), and use this API from the other services to query/update data. This way the DB can change, and API should remain more stable, but you may lose transactionality this way.

Choose whats the most economic, developer-friendly or best for short/long-term for your project.

David Szalai
  • 2,363
  • 28
  • 47
  • Thanks for your answer. Actually, what you said crossed my mind and it makes sense to me. However, we are talking about online (triggered by user screens) - offline (services used by batch) restfull services. There are some batches using online services, and consider that these batches process more than 3000 data, and if we work on the common API for each add or update process, it may cause performance issues for us. Also, both teams will use the same database. –  Jan 27 '21 at 06:23
  • Yeah, I listed a few possible solutions because only you can choose which is the best fit for your project. Also, don't overarchitect it early on, but keep refactorings possible. You can go with shared lib/duplicated code for each project, and later refactor it to APIs if needed (project grows, etc...). – David Szalai Jan 27 '21 at 13:21