Microservices explained
Microservices are new architectural style to develop services which does one thing and does that thing really well. Microservices apply SRP at service layer. So each service exists for a unique reason.
And I think, it makes sense to understand it from perspective of SOA which has been there for a while. Adrian Cockcroft at Netflix, describes Microservices as fine grained SOA.
I have found few really interesting links which explains microservices quite well and in detail. Here are some of them:
http://martinfowler.com/articles/microservices.html
http://microservices.io/patterns/microservices.html
I have also blogged about it over here.
Microservice is an architectural style that is poorly defined. There are several blog posts, essays, and now a book (Building Microservices by Sam Newman) that try to explain microservices. But it became a buzzword and expected characteristics (e.g., "developed by a team that can be fed by 1 or 2 pizzas") vary from one author to another.If we filter out the noise, I think the distinctive factor is that for microservices the deployment unit should contain only one service or just a few cohesive services. I explore this point in a short blog post.
In your example, all else being equal, you would have distinct microservices, such as:
- account (self registration, password reset, login, etc.)
- catalog (items with their price, description, and stock information, and search capabilities)
- purchase order
These services are expected to communicate among themselves using http (REST) and/or events via a message broker. And your design should minimize communication between microservices. How to do that? One idea is to design microservices around DDD bounded contexts. In any case, microservices is not a good idea in all cases, and you should be aware of the tradeoffs involved.
I think the service you describe are too small to be practical. You can better solve it with a servicelayer that does the needed stuff.
Following http://martinfowler.com/articles/microservices.html microservices should not be too small and not too big.
How big is a microservice?
Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.
This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.
In your shopping application I think you can have the following services:
- Financial service (creating invoices, handling payments, etc..)
- Logistic service (sending products, creating orders, etc..)
- API connecting the services
- Frontend talking to the API