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

Bounded context/domain-driven design

As part of the application design, the business domain needs to be broken down into smaller subdomains or business capabilities. We need to carefully examine the business entities and their attributes to define service boundaries. For example, in the case of customer ID entity, the address of the customer might be integral to the customer. Within the context of the application, address maintenance might be a separate activity and might need to be handled separately. Similarly, customer preferences or shopping habits might be required for personalization. In this case, the personalization engine is more interested in this set of attributes.

Should we be slapping together one big customer service having all kind of attributes or can it be divided based on the perspectives derived from the business? These different perspectives are what led to the definition of bounded context as part of the domain-driven design.

The bounded context is a domain-driven design paradigm that helps to add a seam and create service groups. Bounded contexts work in solution-space to indicate that the services are related and belong to a common functional domain. It is built by one team that works with one business unit as per Inverse Conway's law. A bounded context may communicate with the other services/business capabilities through:

  • Exposing internal APIs or services
  • Emitting events on the Event Bus

A bounded context may have its own data store common to services or adopt a data store per service paradigm.

Each bounded context has a life of its own and forms a product. Teams are organized around these bounded contexts and they take the full responsibility of the full stack implementation of the services. The teams are cross-functional and bring skills from development, testing, user experience, database, deployment, and project management. Each product might be split into smaller sets of services that communicate asynchronously with each other. Remember, the focus is not on a set of functionalities but rather on business capability.

We start building our services around business capabilities. The service owns its business data and functionality. The service is the master of such data, and other services cannot own any of this service data.

主站蜘蛛池模板: 五寨县| 丽江市| 通榆县| 平邑县| 平和县| 武邑县| 天柱县| 塔河县| 灵武市| 石狮市| 永寿县| 尚志市| 佛冈县| 石楼县| 陆川县| 翁牛特旗| 武宣县| 策勒县| 准格尔旗| 衢州市| 南充市| 固原市| 松桃| 缙云县| 英德市| 阿勒泰市| 太谷县| 左云县| 迁西县| 台北县| 鄂温| 彭阳县| 谢通门县| 陇西县| 正安县| 宣威市| 奉新县| 岳西县| 清苑县| 新乐市| 临沂市|