官术网_书友最值得收藏!

Loosely couple

No microservice exists on its own, as any system needs to interact with others, including other microservices, but we need to do it as loosely coupled as we can. Let's say that we are designing a microservice that returns the available offers for a giving customer, we may need a relation to our customer, for example, a customer ID, and that should be the maximum coupling that we may accept.

Imagine a scenario that for a component that uses our offers, the microservice needs to display the customer name when it displays those offers. We could modify our implementation to use the customer microservice to add that information to our response, but in doing so, we are coupling with the customer microservice. In that case, if the customer name field changes, for example, to become not just a name but is separated into surname and forename, we need to change the output of our microservice. That type of coupling needs to be avoided; our microservices should just return what information that is really under their domain.

Remember that our domain experts could help us in understanding if a business capability owns a function; probably the experts in customer offers will know that the customer name is something that is a handle in another business capability.

We need to take care of how we are coupling, not only between microservices, but with everything in our architecture, including external systems. That is one of the reasons why every microservice should own its own data, this including even a database where the data is persisted.

主站蜘蛛池模板: 固原市| 连平县| 恩平市| 临江市| 肇源县| 磐石市| 芜湖市| 澳门| 德保县| 乌兰浩特市| 县级市| 潼南县| 仁化县| 张家港市| 山西省| 上饶市| 房山区| 隆安县| 唐海县| 孟津县| 固阳县| 太仆寺旗| 瑞安市| 老河口市| 太谷县| 双流县| 宜君县| 手游| 阿尔山市| 静海县| 阿勒泰市| 邮箱| 榆社县| 芷江| 定州市| 二连浩特市| 桦甸市| 新竹市| 贵南县| 汶川县| 将乐县|