4 Domain ownership

 

This chapter covers

  • Designing domain-oriented data products
  • Defining domain and understanding how it can be decomposed
  • Establishing data product boundaries
  • Defining ownership of data products

This chapter focuses on the data mesh’s domain ownership principle. Domain ownership is about decentralizing responsibility for data and shifting it to business domains. This shift is a stark contrast to the popular model of centralizing data responsibility within the central data team.

What does decentralizing responsibility mean for an individual development team? If you take a team that builds a software component allowing users to register, this component creates data—user data. In the old world, a data team would probably query the developer team’s database to get the user data for creating user registration dashboards. This is data as a by-product. If the responsibility is with the developer team, however, the data team should ask the developers to provide the data in a way that is suitable for the task, and the team owning the data should expose it in the expected way.

The logic behind decentralization is that the people closest to a business area know the most about its generated data and are best suited for tasks related to that business area. You might ask how being closest to the business area is helpful when it comes to data.

4.1 Capturing and analyzing domains

4.1.1 Domain-driven design 101

4.1.2 Invite the right people

4.1.3 Choose the correct workshop technique

4.2 Applying ownership using domain decomposition

4.2.1 Domain, subdomain, and business capability

4.2.2 Decompose domains using business capability modeling

4.2.3 How are domains and business capabilities related to data?

4.2.4 Assign responsibilities to the data-product-owning team

4.2.5 Choose the right team to own data

4.3 Applying ownership using data use cases