I prefer the "share nothing" philosophy. IMO a bit of duplication is better than a shared lib that needs to be maintained, versioned, ...
In my experience, code that has begun as a piece of duplication evolved in separated ways eventually. Beginning with a shared library per default would kill such an option.
The example services are implemented quite similarly, but just imagine a different kind of database (NoSQL) used in one of them. In that case, the ProductId implementations would differ from each other.

The example services are implemented quite similarly, but just imagine a different kind of database (NoSQL) used in one of them. In that case, the ProductId implementations would differ from each other.

@ttulka , I understand your points, but I see the examples you are giving can be handled by abstractions. In general, I think if the domain layer represents the model of the business/problem, the components of it correspond to the real-world concepts related to that business, therefore, should be consistent throughout the application. For instance, it makes more sense for the Accounting, Sales, Product subdomains to use the same Money value object. The implementation details should be the responsibility of DTO's and mappers.

These are my views on the topic. I would be happy to hear your objections against these arguments.

@elnurvl I am not sure, what you mean by "abstraction"...? If you mean an interface ProductId with concrete implementations in particular services, I think this would be a correct approach. I'm used to taking a shortcut to save some typing where I don't see a clear benefit (and I do see drawbacks such as a shared lib) to avoid an explosion of not particularly useful interfaces, but it would be conceptually okay.
Money is a different thing because it is a truly reusable component. That's why I did implement it as a common lib class.