Not parent, but I can share my own experiences as to why you might not want to share business logic. The short answer is you couple your microservices together

Not parent, but I can share my own experiences as to why you might not want to share business logic. The short answer is you couple your microservices together and bring yourself one step closer to a distributed monolith with all its attendant pros and cons. This is especially so if you're in an OO world where data and logic are coupled together so that sharing business libraries often entails sharing business data models. This is also aggravated by the fact that the nature of business logic makes backwards-compatibility difficult to achieve (behavior often changes even if the programming API remains the same). This means changes to business logic libraries often require all downstream users to upgrade immediately or risk inconsistency (which negates the purpose of using a single library in the first place). Shared libraries when using microservices really only work well if it's reasonable to have multiple versions of that library running across different services. In other words, to some degree the sharing is only coincidental in nature. The conventional wisdom around microservices as far as I'm aware is to try to segregate services by business function (rather than e.g. segments of your domain model) to minimize sharing of business logic. Extensive sharing of business logic is a good indication your services are not split across proper lines. Of course getting these divisions down is really hard and therein lies the heart of why getting microservices right is hard.