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: