microservices - is it one service per CRUD

Question

Very new to microservices...

If I have an API that deals with CRUD for customers and orders, does this translate to 2 microservices one for customers and one for orders?

Customer API

CreateCustomer
ReadCustomer
UpdateCustomer
DeleteCustomer

Order API

CreateOrder
ReadOrder
UpdateOrder
DeleteOrder

Answer 1

From a purely technical perspective, the smaller the microservice the easier it can be developed quicker (Agile), iterated on quicker (Lean), and deployed more frequently (Continuous Delivery). But on the modeling side, it is important to avoid creating services that are too small. According to Vaughn Vernon (Author of IDDD Book), we cannot arbitrarily reduce the size of a bounded context because its optimal size is determined by the business context (domain). Our technical need for the size of a service can sometimes be different (smaller) from what DDD modeling can facilitate. This is probably why Sam Newman, very carefully, called bounded context analysis an excellent start, but not the sole prescription for how to size microservices. Bounded contexts are a great start.

Answer 2

We usually cut our services on aggregate boundaries. Domain Driven Design fits very well with microservices, as it helps designing the aggregates with loose coupling. I would recommend doing that first and never reference the order in the customer and vice versa. Only communicate via Domain Events. This way the decision to run one aggregate on another process or server is just an implementation detail and can be done later.

If you split them up in two services you will have to implement some form of communication. This is usually more expensive to implement then running them on the same process, but you get more flexibility in terms of scaling. In your case with only two aggregates, I would keep them on one service. One big plus of microservices should be that they are so small, that you can just delete, rewrite and replace it. I think with two aggregates this is still possible and therefore not worth the hassle.

But again, doing a mircorservice architecture should be an implementation detail. Your domain has to be designed well first or otherwise cutting aggergates into services will be a nightmare.

The only plus for creating microservices up front is, that you already start designing with the fact in mind, that you can not just reference another aggregate and read some propeties to decide something. Wich can be valuable if your team is not used to DDD or loose coupling.