I have two micro services and each of them resides in its own repo.
RepoA depends on repoB/entityB.
repoB depends on repoA/entityA.
Maybe I should put entityA and entityB into a separate common repo. But consider the following case:
I have 10k repos(A, B, C, D, 1, 2, …996).
RepoA depends on repoB/entityB.
RepoB depends on repoA/entityA.
RepoC depends on repoD/entityD.
RepoD depends on repoC/entityC.
If I put entity A, B, C, D into the common repo, it’s kind of strange because repo1…996 doensn’t need it at all.
Should I keep entityX in repoX, and use the go module feature (two modules in repoX, one of them is for the entity X)?
What’s the best practise for it?
Expanding what @hollowaykeanho asked if each of your services are modules you can turn your entities into packages to that module and import each others package without a problem (I hope so). Or you could actually create an entity module where your have all your entities placed and turn them into separate packages and import them in your service modules. I had the same problem when testing out micro and looking for a directory layout for my application and I decided to go with a one repo approach.
This looks like a trap for cyclic import to me if it is not handled properly. If both RepoA and RepoB cross depends on one another, you should have a library module (call it RepoLib1) having each entity to have its own sub-package for easier import.
In other words, this should always be the practice:
RepoA depends on RepoLib1/DataB (package holding entityB type definition).
RepoB depends on RepoLib1/DataA (package holding entityA type definition).
To choose whether to retain these entity packages under small library package or use a common large repo (e.g. repoLib instead of repoLib1) depends on other factors such as:
The way maintainers (not just you alone) maintain the 10k repo.
1.1. Consider the fact that will changing the entity structure breaks the repo and how fast can the team amends those problems and releases it.
1.2. Consider the frequency you upgrade/downgrade a repo affecting the changes to its corresponding entity.
1.3. Consider how the customers use those libraries (for me I won’t use it unless you cleared the potential cyclic import problem).
That way, you can roughly have clear picture on whether to create many library repo or single common repo. Both works and it is a matter of preference.