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

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.

主站蜘蛛池模板: 田阳县| 炎陵县| 正阳县| 宿松县| 湟中县| 庐江县| 河北省| 郯城县| 紫云| 泰顺县| 芦山县| 碌曲县| 海林市| 象州县| 三原县| 兴国县| 南昌市| 潢川县| 来凤县| 乳山市| 桂东县| 黄梅县| 磐安县| 高清| 扎囊县| 忻城县| 宝清县| 清水河县| 巴彦县| 元江| 瓦房店市| 成安县| 奉节县| 扎鲁特旗| 丽江市| 乌拉特前旗| 大安市| 周至县| 二连浩特市| 台山市| 石林|