Re:Should that be a microservice? Factors to keep in mind
by staticassertion on Sunday April 21, 2019 @12:16PM
(#19712765)
Well, I think one answer is to add another service in front of that shared business entity that exposes an interface to match the domain of the consumers. Now the shared codebase should be a stable client.
But yeah, of course there's shared code between your codebases - things like JSON libraries, etc, are always going to be shared. The issue is more about what you're sharing - if it's a very stable, small library, it's probably fine. If it's something really core that's going to change a lot, or that two services may diverge in agreement upon, duplication may be worthwhile.
Re:Should that be a microservice? Factors to keep in mind
by Daishiman on Tuesday April 23, 2019 @07:53PM
(#19734224)
But this is really not any more useful than a monolith. You're applying a complicated criterion for something that should be simplifying my life, and now it's just making things harder in every services.
Again, the default should be a no.
Let's say that you have two microservices that work on the same business entity which is important to your application - eg, an invoice in an invoicing application. Not having shared code means that that you need to write from scratch all the code that deals with that entity for both services. If you later need to add some new attributes which are relevant to both services, you'll also need to independently update the code in both services, including the testing, and to do double the debugging.
If the services are really "micro", this will happen even more times for the same entity.
How can you do this without doing a lot more coding than if you had shared code?