Microservices is Service Oriented Architecture done well. It is based on creating small services (micro-sized) that are focussed on a business domain and are small enough to be called Micro. Every microservice service should be doing one thing (one thing only) and doing it very well. should be light weight and technology agnostic and communicate via something like http REST, each service should own its own database and be independently changeable and deployable. Every transaction will most likely be completed by many services and because there are many services there should be a way to monitor them.
Every Microservice should be Coherent and that means it is focussed on doing one thing, it should not change because another service is changing or a new column in some database is being added. That means when adding new functionality you should add a new micros service. You micorservice should have only one reason to change.
Autonomous, Should be independent and own its contracts, independently developed. should probably respond right away via asynchronous patterns, you should also look into Message Queue, RabbitMQ and ATOM. Observable, You should have a central monitoring System to know what services are operational now and what is their individual health status. monitor exceptions, centralized logging, maintain correlation ID, etc.. there are many software solutions that provide this out of the box already like Azure Service fabric. basically every service should be able to register itself so that other services can discover it is up and running. Resilient, Services should also be able to fail gracefully and provide default values when they are not operational.
You may however provide an API gateway for all clients as an entry point for all Microservices. the API gateway can perform some common tasks like authentication and then relay to the specific microservice.
Every microservice should own its own database, for shared data you can create a separate microservice for static or shared data but should not provide a single monolithic service for all system wide CRUD operations since it will continuously change which is against the first princible which is cohesion.
Every Microservice should be Coherent and that means it is focussed on doing one thing, it should not change because another service is changing or a new column in some database is being added. That means when adding new functionality you should add a new micros service. You micorservice should have only one reason to change.
Autonomous, Should be independent and own its contracts, independently developed. should probably respond right away via asynchronous patterns, you should also look into Message Queue, RabbitMQ and ATOM. Observable, You should have a central monitoring System to know what services are operational now and what is their individual health status. monitor exceptions, centralized logging, maintain correlation ID, etc.. there are many software solutions that provide this out of the box already like Azure Service fabric. basically every service should be able to register itself so that other services can discover it is up and running. Resilient, Services should also be able to fail gracefully and provide default values when they are not operational.
You may however provide an API gateway for all clients as an entry point for all Microservices. the API gateway can perform some common tasks like authentication and then relay to the specific microservice.
Every microservice should own its own database, for shared data you can create a separate microservice for static or shared data but should not provide a single monolithic service for all system wide CRUD operations since it will continuously change which is against the first princible which is cohesion.
