4

So I have read shared libraries in micorsevrice ae bad, becuase they dont allow complete autonomy of the service to evolve.

And example:

Service A and Service B both talk to Service C to view some data.

I can create the domain objects in each service and copy the code from Service C.

OR

I can share a shared library between the services.

Now i know if i need to chnage the shared library il have to deploy the 3 services again.

BUT

If i duplicate code and I find a bug in the original code, I still need to deploy all 3 services as the code is copied so there still is a ripple affect.

So why is sharing so bad, in my example?

user1555190
  • 2,803
  • 8
  • 47
  • 80

4 Answers4

3

You are almost always going to have some common components between different services.

  • For Example: most services will communicate via TCP and often HTTP. Do you need to find a different library to handle TCP or HTTP communication for each service? NO

  • In your example, it sounds as though the shared library would just be a common way for Service A and Service B to communicate with Service C. This is very similar to having common code for handling a communication protocol

  • Decoupling services is desirable for many reasons and should be strived for if at all possible. But when it is impractical then it is up to the developer(s) to decide on a course of action. As other people have pointed out, you may want to consider redesigning your system so that these common dependencies are removed. But as I don't know the context and this has already been pretty well explained by others - I will leave that at that and focus on the rest of the question

  • If you need to share code between services, and the services are written in the same language then I would do it with one library. Yes you will have to deploy the library to all servers for any changes. But at least the changes will only happen in one place.

  • Personally, I don't see any benefit at all in breaking this into different libraries. It's confusing - You'll have to remember your different implementations. If both break, you have two fixes to make. If something changes you have two places to make the change.

  • How decoupled would two implementations really be anyways? they are both doing the same thing, both depend on the same data and both are likely to be designed by the same person with the same understanding of the problem. If there are bugs in one then there will probably be similar bugs in the other.

Arran Duff
  • 1,214
  • 2
  • 11
  • 23
1

Primary goals of microservices is to create loosely coupled ,scalable services which can be changed independently from other services. The creation of our share libraries or domain objects creates coupling between the projects.

Developers of microservices need to embrace the reality that duplication of code between microservices

Start design monocytic first then break your code into Bounded context.

Bounded Context defines the boundaries of the biggest services possible: services that won’t have any conflicting models inside of them so Bounded context is a projection in the solution space to define boundaries in the system implementing the domain.

Rule of thumb one bounded context = one microservice with single responsibility .

  • Start with analyzing the business domain
  • Based on the domain analysis, find the sub-domains
  • Come up with a solution (Bounded Context) to a sub-domain
  • Map each Bounded Context into a microservice

Always remmber Microservice emphasis should not be on the size but on the business capabilities.

If you need to share your domain among services so you have created Nano services instead of microservice and Nano service is antipattern.

vaquar khan
  • 10,864
  • 5
  • 72
  • 96
  • 1
    Bounded context defines the boundary between concepts of the system, concepts which are defined by the ubiquitous language. There is no ambguity. As for sharing, im going to disagree, it depends on the rate of change and how much chnage is going to take place. DDD has the shared kernel... to enable the model to be shared between contexts... and even if i was to duplciate code, the inherent issue of fixing a bug int he code and affecting all services is still present... this then brings me to the interchange context?.. maybe thats what i need... – user1555190 Feb 07 '19 at 09:13
  • Microservices is architectural style not a framwork where we choose few principle and left few based on pros and cons ,there is another architecture style called mini service which give you flaxiblity what all u like u can use (find in github link I shared) ,you always free to decide what style you want even many benefits available on old monolythic applications, spl when u deploy on cloud and ingress and egress traffic and deployment compute cost.since you and I not define architecture we need to follow the rule same like english grammar or Chinese grammar – vaquar khan Feb 07 '19 at 12:19
  • Few components like security or exception handling or runtime spring jars thses code I can understand if you are thinking to create compile time dependance using maven module but business logic and domain is not acceptable to share as share lib. – vaquar khan Feb 07 '19 at 12:24
0

If you copy the service over to both places instead of directly using it from the same source that is still sharing. That still does not allow autonomy, as you correctly pointed out.

You should redesign all 3 services to not have this conceptual dependency at all. I suspect this dependency is there because you have some "data" that A and B need that C has. Instead of that, try coming up with a different kind of split where services offer functionality (not data) that they themselves can fulfill without other services.

This is admittedly not always easy, but that is what's behind this "do not share business logic" policy.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • That is a valid comment, however the data i want to share is common accross various bounded contexts, service A,B being one, another could be Service X and Y. So that leaves me with same problem.. Im willing to accept the shared kernel approach to this, since we have one team manageing all the services (bounded contexts) – user1555190 Feb 06 '19 at 12:01
  • I obviously don't know your use-case. But. A *bounded context* means that it has bounds. As in, there is a clear boundary between concepts inside and the outside. Sharing data is by definition sharing concepts, which means it is not bounded at all. Usual mistakes of unbounded contexts: designing CRUD "microservices", like Customers, Orders, Products, things like that. I have to come back to: you don't want to share data. If you do that the dominoes start to fall and you'll face conceptual problems like the one you posted. – Robert Bräutigam Feb 06 '19 at 12:18
  • Not sure about sharing concepts, since bounded context does not mean you cant share a concept, its the meaning you give that concept that is the boundary, a customer to order department has a different meaning to customer to an accounting department. I also accept a system can never be perfect system. yes the use case for me makes the shared data a requirement accross the whoel system... and duplciating doesnt sit well... – user1555190 Feb 06 '19 at 12:36
0

In your example sharing is bad because you are recoupling what u have decoupled.

Service A and Service B both talk to Service C to view some data.

If Service A and B are using a shared library, then changes from Team B are effecting the service of Team A as well. Maybe Team A doesn´t knows about the changes or the changes are just fitting to Service B.

Pierreros
  • 131
  • 1
  • 5
  • But the concept of sharing is not bad, surely we must accept exceptions to the rule... DDD has the shared kernel? – user1555190 Feb 07 '19 at 09:15