Design of a single microservice, size limit?

Question

I've been struggling for a while of what would be the "recommended" approach for a microservice itself.

There are quite of top architecture designs that are the holy sacred for a lot of craftsman devs, such as CQRS, Hexagonal, DDD, etc...

But from my point of view, depending of how "big" is the microservice, because you know the word itself it's giving you a hint... "micro"!!

Should I consider build all the packages, interfaces, divisions between layers such as Hexagonal, or split the content of the microservice based on DDD (its supposed that 1 microservice its 1 domain??? if not... :| kind of WTF??)

Or just keep it on its essence like split the entrypoints(rest,queues)-core(business logic)-outpoints(DB,queues, or whatever) and let it open for a "little" extension.

If its too big, think on a split? In order to avoid "minimonolits" and what would be the limit to consider an "app"/API a microservice or a little monolit?

Maybe to be more clear.

i.e:

Microservice/API
├── Product
│   └── DDD/CQRS/Hexagonal stuff
|       └── ....
├── Sells
│   └── DDD/CQRS/Hexagonal stuff
|       └── ....
└── Customer
   └── DDD/CQRS/Hexagonal stuff
       └── ....

Microservice with basic crud -> Product-Sells-Customer(with patterns such as CQRS, Hexagonal, etc...?) -> Its a minimonolit for me.

The kind of what I look forward...

Gateway microservice
├── Product
│   └── routing stuff
|       └── ....
├── Sells
│   └── routing stuff
|       └── ....
└── Customer
   └── routing stuff
       └── ....

Product

Product Microservice
├── Product
   └── Basic separation layer(REST/SERVICE/ORM-QUEUE)
       └── ....

Sells

Sells Microservice
├── Sells
   └── Basic separation layer(REST/SERVICE/ORM-QUEUE)
       └── ....

Customer

Customer Microservice
├── Customer
   └── Basic separation layer(REST/SERVICE/ORM-QUEUE)
       └── ....

The previous ones should have patterns such as CQRS, Hexagonal, etc...???

Answer 1

The key thing to keep in mind is “microservices should be independently deployable and scalable”. If your framework and dependencies make your microservices need to be deployed en masse, you lose almost all of the benefit (and incur a lot more cost). That will drive a lot of your decisions about where to split things. Literal size doesn’t matter as much as coupling does.

In general, the depth of your layers matters less than the breath of the API surface area since layer coupling doesn’t usually prevent independent deployment. Where you run into problems is when different services access the same db - so need schema changes done together. Or when different services use the same authorization, so deploying one with an upgraded scheme causes auth failures. If each service’s presentation is coupled to its ORM... well, that’s unfortunate but you can still deploy your tiny service without breaking its neighbors.