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

Organizing around bounded contexts

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure"

- Melvyn Conway, 1967

Generally, the organization structure contributes heavily to the design of the application. Therefore, bounded contexts should never be identified on the basis of the existing structure of the organization. Instead, the organization must be structured around bounded contexts such that the entire team can work on a service in isolation.

A typical organization, working on a monolithic application, is built around layers of presentation, business logic, and persistence, as shown in the preceding diagram. They tend to have a separate team of UI designers and UI/UX experts for the presentation layer, a team of backend developers to implement the domain model, and a team of database administrators to create a database for developers to access. Such an organization structure is ideal for an application with a smaller set of business capabilities.

Once the application grows, any changes to the application require communication to be made across the team of UI engineers, backend developers, and database administrators. Often, such communication leads to so many back-and-forth exchanges involving design documents and specification changes that it becomes overwhelming for the teams to translate the requirements correctly to the implementation. Such communication overhead adds delays to the project and brings down the productivity of the entire team working on the product as a whole.

Bounded context, if identified correctly, solves this problem by localizing the team of UI developers, backend developers, and database administrators to focus on a single business capability. Such boundaries make sure that the communication between the teams is bounded by a fixed contract that is set at the service level. This makes it possible to reduce a considerable communication overhead, as any changes made to a service are confined within the team working on the service. For example, the localized team of User Service and Orders Service will communicate only to discuss the service APIs that the user service is exposing for Orders Service to get the customer details. Since any changes to the customer schema or the orders schema should not impact each other as per the definition of bounded context, it is not required to communicate such changes to the other service.

主站蜘蛛池模板: 博客| 扬中市| 遂昌县| 大余县| 普兰县| 呼伦贝尔市| 台东县| 河西区| 宁国市| 镇雄县| 资源县| 保康县| 修文县| 邛崃市| 高邮市| 岫岩| 高阳县| 梓潼县| 高密市| 文昌市| 星座| 华安县| 萨迦县| 通辽市| 竹山县| 奎屯市| 区。| 湟源县| 阜平县| 宽甸| 年辖:市辖区| 长子县| 大城县| 南部县| 福建省| 偏关县| 新化县| 盖州市| 永昌县| 永平县| 通道|