One of the advantage of microservices is that each microservice can evolve relatively independently from the other, due to a looser coupling.

Keeping the monolith library and reusing it in all the microservices would not fit into the logic, because you'd have many more dependencies that you'd ought to have. The only advantage that would gain from such a pseudo-microservice approach would be an easier distribution of your services, so perhaps a better scalability.

Another important point to consider is that each microservice should be responsible for its own data. Having lots of microservices using a single monolith database would somehow miss the point. This suggest that what is domain data access for one microservice, should be domain service request for another one.

The glue library for the interfaces is a first step to decouple a little bit more the services. However I think it would still avoid independent evolution of each microservices. I'd rather opt for this alternative:

• Domain-driven interface libraries
• Implementation of microservices, segmented by domain (not necessarily in a library), but using the corresponding interface library.
• Domain-driven service consumption libraries depending on the respective interface libraries (distinct library for each domain/microservice)
• Applications using microservices would reuse these service consumption libraries, but only the needed one.

The advantage of this approach compared to the glue library, is that:

• dependencies between microservices are explicit (use of consuming libraries) and reduced to the strict minimum.
• dependency between consumers and service is isolated in the interface library.

One of the advantage of microservices is that each microservice can evolve relatively independently from the other, due to a looser coupling.

Keeping the monolith library and reusing it in all the microservices would not fit into the logic, because you'd have many more dependencies that you'd ought to have. The only advantage that would gain from such a pseudo-microservice approach would be an easier distribution of your services, so perhaps a better scalability.

Another important point to consider is that each microservice should be responsible for its own data. Having lots of microservices using a single monolith database would somehow miss the point. This suggest that what is domain data access for one microservice, should be domain service request for another one.

The glue library for the interfaces is a first step to decouple a little bit more the services. However I think it would still avoid independent evolution of each microservices. I'd rather opt for this alternative:

• Domain-driven interface libraries
• Implementation of microservices, segmented by domain (not necessarily in a library), but using the corresponding interface library.
• Domain-driven service consumption libraries depending on the respective interface libraries (distinct library for each domain/microservice)
• Applications using microservices would reuse these service consumption libraries, but only the needed one.

The advantage of this approach compared to the glue library, is that:

• dependencies between microservices are explicit (use of consuming libraries) and reduced to the strict minimum.
• dependency between consumers and service is isolated in the interface library.

One of the advantage of microservices is that each microservice can evolve relatively independently from the other, due to a looser coupling.

Keeping the monolith library and reusing it in all the microservices would not fit into the logic, because you'd have many more dependencies that you'd ought to have. The only advantage that would gain from such a pseudo-microservice approach would be an easier distribution of your services, so perhaps a better scalability.

Another important point to consider is that each microservice should be responsible for its own data. Having lots of microservices using a single monolith database would somehow miss the point. This suggest that what is domain data access for one microservice, should be domain service request for another one.

The glue library for the interfaces is a first step to decouple a little bit more the services. However I think it would still avoid independent evolution of each microservices. I'd rather opt for this alternative:

• Domain-driven interface libraries
• Implementation of microservices, segmented by domain (not necessarily in a library), but using the corresponding interface library.
• Domain-driven service consumption libraries depending on the respective interface libraries (distinct library for each domain/microservice)
• Applications using microservices would reuse these service consumption libraries, but only the needed one.

The advantage of this approach compared to the glue library, is that:

• dependencies between microservices are explicit (use of consuming libraries) and reduced to the strict minimum.
• dependency between consumers and service is isolated in the interface library.

One of the advantage of microservices is that each microservice can evolve relatively independently from the other, due to a looser coupling.

Keeping the monolith library and reusing it in all the microservices would not fit into the logic, because you'd have many more dependencies that you'd ought to have. The only advantage that would gain from such a pseudo-microservice approach would be an easier distribution of your services, so perhaps a better scalability.

Another important point to consider is that each microservice should be responsible for its own data. Having lots of microservices using a single monolith database would somehow miss the point. This suggest that what is domain data access for one microservice, should be domain service request for another one.

The glue library for the interfaces is a first step to decouple a little bit more the services. However I think it would still avoid independent evolution of each microservices. I'd rather opt for this alternative:

• Domain-driven interface libraries
• Implementation of microservices, segmented by domain (not necessarily in a library), but using the corresponding interface library.
• Domain-driven service consumption libraries depending on the respective interface libraries (distinct library for each domain/microservice)
• Applications using microservices would reuse these service consumption libraries, but only the needed one.

The advantage of this approach compared to the glue library, is that:

• dependencies between microservices are explicit (use of consuming libraries) and reduced to the strict minimum.
• dependency between consumers and service is isolated in the interface library.