- Cloud-Native Applications in Java
- Ajay Mahajan Munish Kumar Gupta Shyam Sundar
- 360字
- 2021-06-24 19:07:19
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.
- 密碼之謎
- LED封裝與檢測技術(shù)
- 圖解電子技術(shù)速學(xué)速用
- 車聯(lián)網(wǎng)
- 5G來了:5G如何改變生活、社會(huì)和產(chǎn)業(yè)
- 視頻精講:PADS 2007原理圖與布板設(shè)計(jì)典型實(shí)例
- Network Programming with Rust
- Android App Inventor項(xiàng)目開發(fā)教程
- 現(xiàn)代移動(dòng)通信技術(shù)與系統(tǒng)(第2版)
- 全程圖解變頻器應(yīng)用與檢測技能
- 現(xiàn)代通信技術(shù)及應(yīng)用(第3版)
- PTN分組傳送設(shè)備組網(wǎng)與實(shí)訓(xùn)(第2版)
- 電子電路知識(shí)與實(shí)踐課堂
- H3CNE實(shí)驗(yàn)手冊
- NFC技術(shù)原理與應(yīng)用