- microservices are small. Some microservices run 1000 of them
- Independently deployable: replace x by y with changing anything else
- Successful microservice architecture should implement DDD (Domain Driven Desing)
- Handling microservices depends on logging
- In microservices there is no too much testing, most of the testing is done by unitesting. Manual testing is not possible because the systems is highly random
- Microservices can be seen as an object and pull ideas from OOP:
- delegation!
- hide data
- do things!
- You should not know who is talking to? no IP or names!
- BASIC RULE: replacement principle. YOU SHOULD BE ABEL TO RADICALLY CHANGE THE IMPLEMENTATION OF A CLASS WITHOUT IMPATNING THE CLIENTS.
- Bounded context: a way of model business. Example
- context of the store:
- books: a name author
- cashier...
- context warehouse:
- books: how heavy, size
- Context microservices are isolated!!! they connected via ports.
- context of the store:
- Ubiquity languages which is a kinda language. translating protocols
- UI: the agent architecture.
- each view has it own controller database and private communication API
- Communication. No SOAP, No REST. Nothing CRUD! accessing data! Therefore RabbitMQ or ZeroMQ are good choices
- DDD is the ideal software design paradigm that fits the nature of microservices very well
- The model should reflect the structure of the organization
- Microservices focus on security since all calls implement authentification checks in the destination service.