I've been reading a lot about micro-services lately, and here are some of the conclusions I got so far (please correct me if I'm wrong at any point).
- Micro-services architecture goes well with domain driven design. Usually one MS represents one bounded context.
- If micro-service A requires functionality which resides in the micro-service B, my model is probably wrong and A and B should actually be one micro-service / BC.
- Synchronous communication between micro-services (direct HTTP requests) is bad, cause it defies the purpose of micro-services, and introduces coupling between components.
- Asynchronous communication between services is desirable. Services should publish events to message queues, so other services can subscribe and process their part of the event, or use it to replicate a portion of data needed for their context. This way, services can process requests even other services are down, which would not be the case in the synchronous communication.
- If micro-service A publishes event, micro-service B subscribes to that event and produces a new event as outcome, micro-service A should not be the one processing newly created event, cause that would be a circular dependency. In this case, we should introduce third micro-service, or combine A and B in to AB micro-service.
- Micro-service is actually a misleading term. We should strive for small contexts, but that does not need to be the case. Term should not be "micro-service", but "big enough to do the job service".
- Micro-services allows us to introduce new functionalities with more ease and without fear that we will break entire system. It can be done by introducing a new service, or refactoring one of the existing.
- Each micro-service should have it's own data-storage. Data replication/duplication is desirable behavior in this architecture.
Other than confirming my understanding of this architecture, my other part of the question is mostly related to service discovery. If the services are communicating asynchronously, and using central event queue like amazon SQS, does that mean that service discovery does not have its place in architecture like that?
Services should not have any knowledge about other services in the system. They are only aware of their context and events they should publish or subscribe to?