Implementing microservices architecture, managing its interdependencies

Imagine a OAuth provider using microservices. We will have microservice for authorization endpoint, token endpoint etc.

For example, every endpoint is different microservice and most endpoints will need to retrieve client by id to authenticate request. So how should I share method to get client from database, model for client and all related to it entities?

How shall I share common methods and classes between microservices?

If microservice A depends on microservice B, then I need to do communication between them over HTTP or I just can add project reference? Or maybe situation where some microservice depends on another is bad and says that our services are too micro?

Does scenario where we use DDD in our microservices says that our microservices are too big (or it adds too many complexity)? If they are really micro, doesn't it mean that some simple folders like Models, Services and Endpoints are enough?

> So how should I share method to get client from database, model for client and all related to it entities?

You don't, because sharing database between microservices usually is a very bad practice in microservice architecure.

> How shall I share common methods and classes between microservices?

In general - you should not. You can maintain several libraries for contracts (but you should consider some kind of Schema Registry first) and cross-cutting concerns, but that's it.

> If microservice A depends on microservice B,

The thing is that you should avoid services being depended on each other in traditional sense. Services should be as loosely coupled as possible

> then I need to do communication between them over HTTP

There are cases when you will need some kind of RPC but the general approach is to try avoid synchronous communication between services in favor of asynchronous one (i.e. via some message bus for example)

> I just can add project reference?

If you can add a reference from one microservice on another then you don't have microservices.

> If they are really micro, doesn't it mean

I would argue that term "microservice" is not that well defined in general and from place to place can differ vastly.

Note that the goal of microservice architecture is not to split every endpoint into separate service, actually it can be very counterproductive to do so. I would argue that the main goal is to split your system into loosely coupled or even independent components (ideally as small as possible), actually if you are finding that several components are tightly coupled there are cases when you can just unite them back (or rework architecture so they can be decoupled).

I highly recommend to study the following resources:

• Building Microservices: Designing Fine-Grained Systems 1st Edition
  by Sam Newman

• microservices.io (and Microservices Patterns: With Examples in Java by Chris Richardson)

• Avoiding Microservice Megadisasters - Jimmy Bogard

The point of microservices is that they should be independent. Meaning they can be developed and deployed independently. This may require that each service has a separate versioned, backwards compatible API. Separate databases, etc. Importantly it usually also means separate teams, using separate repositories, separate solutions, and possibly separate languages.

Sometimes an API gateway is used to route requests to services, and this may do some things, like authentication.

Calling other services is not prohibited, and are done thru the public API of the service, whatever protocol that may use. If your services use HTTP you should call using HTTP. But you need to be careful to avoid cascades of calls that can absolutely ruin performance.