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

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.

主站蜘蛛池模板: 西安市| 奉贤区| 桐柏县| 象州县| 仙桃市| 根河市| 遂溪县| 桐庐县| 新河县| 仁布县| 孟州市| 石家庄市| 韩城市| 海盐县| 兴安县| 静乐县| 麻城市| 朝阳区| 蒙阴县| 中西区| 应城市| 永靖县| 肇源县| 宁陵县| 探索| 稻城县| 洪洞县| 抚松县| 芮城县| 黄龙县| 家居| 罗源县| 开化县| 湾仔区| 安国市| 洪洞县| 绥化市| 西乡县| 铜鼓县| 晋州市| 贺兰县|