This article is the fourth in a serie on the Data Mesh architecture. In this article we will focus on how to build Data Products with dbt using the Pragmatic Data Architecture.

This is the fifth article in a serie on the Data Mesh architecture. In this article we focus on how Domain Driven Design and Product thinking collaborate in a Data Mesh approach.

Prerequisites for Data Mesh success

In this serie we have already said that the Data Mesh approach is based on both organization and technology, with organization being the hardest of the two components because changes always faces resistance in people and organizational changes usually involve more people than technical ones.

The Data Mesh cornerstone is to push the development to happen closer to where the knowledge/need is.

This is essentially the same core principle of Domain Driven Design, that aims to identify bounded contexts, an ubiquitous language and draw domain models so that knowledge owners and technologists collaborate.

DDD can be a useful framework to identify the reality and needs of the current organization and how to draw domains and bounded contexts that align with it.

How does product thinking or data products come into this picture?

DDD and Data Mesh suggest to split a bigger thing into smaller parts, so that each can be built with the right knowledge, but if we want to realize the benefits of the bigger thing we have to put these pieces back together.

Product thinking help designing the smaller parts, data products, in a way that can be easily composed. Each solves the problems of their domain, to the benefit of users inside the domain, but to be a product it must also be designed for easy general use, outside the domain.

A product has utility beyond its creator’s needs and often over time can grow to satisfy more needs or multiple types of users. That is where DDD activities like collaborative modeling and strategic design help in moving from an internal solution to a data product able to satisfy the needs a multiple stakeholders. While still being built by the people knowing the domain at best.

I said before and I will repeat it here: if you are not willing to change how collaboration and responsibilities work in your organization you will probably get little to no benefit from a Data Mesh approach.

You might get some better componentization of your data platform, but the real benefit is when the different components -the data products- benefit from the work of a long term, product thinking, knowledgeable team made of technical and domain experts that share the responsibility to make the domain’s data available to all stakeholders and have the autonomy to decide what to develop and how to better satisfy their explicit stakeholders.

In the next sections we will briefly introduce the Domain Driven Design approach, and then we will look at how it helps building better (data) products. We close with some references.

Domain Driven Design basics

Domain Driven Design (DDD) is an approach to build complex software systems.

It is based on the very simple concept that to succeed you need to focus on the core of the problem at hand (core domain) and keep the solution grounded in reality and as simple and understandable as possible.

You do that by anchoring the discussion around a model of the domain, that is valid inside an explicitly defined bounded context where all projects participants, both technical and domain experts, use an ubiquitous language that is clearly defined and understood.

That is simple to say, but much harder to do in practice.

That is why DDD recognizes the importance of three major activities:

1. collaborative modeling
   It is the crucial process through which stakeholders, domain experts, developers and other team members work together to create a common understanding of the domain. It is the real “secret sauce” of DDD.
2. strategic design
   It is the high level activity to understand and organize (by identifying the scope and boundaries) the application/data platform first and -iteratively- the domains and subdomains/business contexts that make it up, documenting how they communicate and their relationships.
3. tactical design
   It is the process to design the individual bounded context, by applying various DDD patterns that help solving common situations. It translates the strategic design into a practical domain model that provides the desired behavior, respects the business rules and drives the code implementation.

These activities are iterated over whenever necessary.

Initially you do them to right size the domain and business contexts, and later to clarify the finding and adapt to changes that emerge.

The result is that our data platform will be split in a number of domains, with one or more bounded contexts inside each domain.

Each domain will have one or more development teams, with one team owning one or more bounded contexts.
To preserve the integrity of bounded contexts it is important that only one team works on each bounded contexts. No sharing.

In a Data Mesh approach a bounded context usually corresponds to a data product, but there might be good reasons to deviate in both directions by having a data product to realize two bounded contexts (from the same team) or a bounded context realized in two data products.

It is beyond the scope of this article to go deeper into DDD, but it is important to recognize how the approach goes in the same direction as the data mesh approach.

Companies that want to pursue a Data Mesh approach can use the body of knowledge from DDD to help them find a good way of working accounting for the existing organization. You can research more on DDD starting with the links in the Reference section.

Domain Driven Design and Product thinking

Figuring out what to build and designing it is important, but it becomes real only when the team tasked to implement it actually writes the code.

As Alberto Brandolini, the creator of the EventStorming technique, said: “it is not the domain experts knowledge that goes to production, it is the assumption of the developers that go to production”.

The goal of DDD is to narrow the gap between the developer’s assumptions and the expert’s knowledge. That does not happen overnight, in a few meetings or just by writing/reading documentation.

It requires long term, iterative collaboration that can really happen when both sides work closely for mutual benefit and long-term aligned interests.

That is why the team structure and way of working are crucial components in making or breaking the success of a data mesh development effort and why I have already said that data products should be developed with product thinking in contrast to project thinking.

The following image depicts the major steps in the software development lifecycle, from deciding what to develop to running it in production, along with common team structures and how information is passed along.

Team structures, Amplitude blog

It should be clear by now that the more handoff need to happen the least the development team will understand of what need to be developed, increasing the risk of getting a square when a circle was needed.

This is the practical exemplification of the first claim in this article. Said differently, the higher your teams are in this picture (close to waterfall) the least benefit you should expect from a data mesh approach, because the developer’s assumption will remain far away from the domain expert knowledge.

If you want to achieve better results you should find ways to move the team structure and way of working towards the bottom of this picture, ideally arriving to a permanent product team organically embedded in the organization.

Learn, Build, Measure phases, Amplitude blog

The previous image superimposes the Learn, Build, Measure phases to the software development lifecycle.

This should make clear that if you want to build a product that focuses on the needs of the “customers”, that is the rest of the organization, and evolves according to their feedback you need to keep the dev team as much as possible in the loop. That would improve both the quality of the results and the development efficiency.

Domain Driven Design provides the processes and patterns to identify the bounded contexts that exist in the organization and foster collaboration between developers, domain experts and other stakeholders.

Product thinking provides a way to prioritize what to build and design how to build it to satisfy the customer needs, learning and adapting in an iterative way.

The combination of these two approaches helps the organization to move between the three spaces of strategic planning:

• problem space, where you understand your domains and subdomains and identify needs and opportunities.
• strategy space, where you chose the direction to go and wich opportunities to pursue.
• solution space, where you design and build the products you decided to pursue.

This problem solving framework is common to all aspects organization management, so in a way we can think of data mesh of an opportunity to make data a normal part of the strategic planning of each part of the organization.

Data savviness is now confined to small areas of organizations and relegated to a scarce set of people therein. That is the root cause of most of the problems in data projects and about data usage. Data Mesh, DDD and product thinking offer solutions to improve the situation.

The normalization of data inside all parts of an organization is, in my opinion, the only way to build really data driven organizations.

It is a base requirement for organizations to deeply trust their data, understand well everyday reports, widely adopt advanced analytics and properly embrace the new AI opportunities.

Conclusion

Through this serie of articles I have discussed the core concepts of the Data Mesh approach and tried to show why building data products makes sense.

I have also discussed that technically it is quite simple to implement data products with the Pragmatic Data Architecture. Technology is not an obstacle.

This should reinforce the idea that most of the problems in data projects are not technical in nature, but come from incomplete, partial understanding of the problem.

Closing the gap between domain knowledge and developer assumption is half of the problem, distributing data competence in the organization is the other half.

The best chance to tackle both sides of the problem is to organize the teams that build the data platform to follow the business organization, so that domain competence can flow towards the developers and data competence can flow towards domain experts and the business in general.

Closing the domain/data competence gaps and treating data as a product is a sound strategy to transform data from an arcane by-product of operations into a familiar and valuable strategic asset.

Operating these teams with a product thinking mindset drives quality results that match the organizational goals efficiently, and can evolve with short time to market to support innovation and new opportunities.

I hope that you have found interesting ideas in this serie and I would be happy to discuss them.

Originally published on 24/02/2025 at https://pragmatic-data.org/

References

• “DDD Reference“, by Eric Evans
  The reference guide provides a quick and authoritative summary of the key concepts of Domain-Driven Design.
• “Journey to Product Teams (Infographic)“, Amplitude blog

Articles in the Data Mesh series

• Why adopt a Data Mesh approach
• The Data Mesh architecture
• Data Mesh and data products
• Building a Data Mesh with dbt and the PDP
• Domain Driven Design and Product thinking (this article)