I have a doubt about Microservices Architecture. We are developing an ERP and there're several microservices such as Human Resources, Identity, Orders and so on.
We've implemented a shared domain layer for entities that are common for all those layers, including abstractions ( interfaces ) of Company, Location and some value objects.
My question is: What's the boundary of shared items for microservices and how bad is that?
In that case, Those shared entities would be the same for each microservice, so that help us to write less code BUT at the same time creates a small level of coupling.
Usually microservice architectures adopt a "share nothing" concept, which mean your code bases should be ideally separate. Yes, that will mean you will write more code but will keep your microservices more manageable, uncoupled and probably lighter.
Also, regarding the DDD-part do the question, you should really strive to keep well defined boundaries within your application, which means you shouldn't be scared to have "redundant" entities in different bounded contexts because the same concept usually mean different things to different domain areas of your application.
Keeping onto the "ERP" theme, you'd expect the "Order Placing" context of your application to have quite a different view on the "Product" entity than that of the "Tax" context. Keeping those in distinct contexts in different code bases will allow you to model smaller aggregates with a higher level of cohesion that will be way less coupled to the other constructs of your model thus, making evolve your microservices way easier.