- Hands-On Microservices with Kotlin
- Juan Antonio Medina Iglesias
- 161字
- 2021-06-30 19:10:40
Single responsibility
Every microservice should have responsibility over a single part of the functionality provided by the application, and that responsibility should be entirely encapsulated by the microservice. The design of the microservice should be narrowly aligned with that responsibility.
We could adopt Robert C. Martin's definition of the principle applied to OOP that said: "A class should have only one reason to change"; for this principle, we can say: a microservice should have only one reason to change.
If we realize that when we need to change a business function within our application, it modifies several microservices, or that a change cascades into non-related microservices, it is time that we reconsider how we design them.
This does not mean that we get to make microservices that do only one operation. Probably it is a good idea to have a microservice that handles the customer operations, like create, find, delete, but probably shouldn't handle operations like adding offers to a customer.
- GitLab Cookbook
- Beginning Java Data Structures and Algorithms
- 程序員面試筆試寶典
- 三維圖形化C++趣味編程
- 新編Premiere Pro CC從入門到精通
- Flash CS6中文版應用教程(第三版)
- Java性能權威指南(第2版)
- OpenShift在企業中的實踐:PaaS DevOps微服務(第2版)
- ANSYS Fluent 二次開發指南
- Keras深度學習實戰
- Laravel Design Patterns and Best Practices
- 用Go語言自制編譯器
- C語言王者歸來
- Getting Started with Hazelcast
- 代碼整潔之道:程序員的職業素養