Split or merge? Tom De Wolf on scoping data products at the POA Summit

How big should a data product be? Our Innovation Lead Tom De Wolf tackled that question at the 3rd Industry Summit on Data Product Oriented Architectures (POA Summit) in Antwerp. In his talk "Split or Merge? Scoping Data Products with Domain Driven Design", he gave practitioners and researchers from across Europe concrete heuristics for drawing the right boundaries.

Tom De Wolf on stage at the POA Summit, hosted by DPG Media in Antwerp.

What is the POA Summit?

The POA Summit brings practitioners and researchers together around federated data management in organisations. The programme covers two themes: how companies move to data product oriented architectures, and how to design and manage modern data products. The third edition took place at DPG Media in Antwerp, with speakers from industry and research across Europe.

The real challenge: getting the size right

Scoping a data product means drawing clear boundaries around it. Get it wrong and you feel it on both sides.

• Too coarse: you end up with a data monolith. Huge codebases, sign-off from several teams for every change, unclear ownership and a security risk, because one product exposes all the data.
• Too fine: users spend weeks finding data and requesting access, write complex joins and get lost in a crowded catalogue. Every change needs coordination, and you end up with a distributed monolith.

Don't reinvent the wheel

Tom's core message: software engineers have been solving similar scoping questions for years, for example with microservices. Domain-Driven Design (DDD) offers proven heuristics for this. They are not strict rules but guidelines that push teams to discuss trade-offs and decide what matters most in their context. Four of them apply directly to data products:

• Ubiquitous Language: if a term like "customer" means something different in different contexts, split it into separate data products.
• Shared Lifecycle: merge data that shares the same lifecycle, such as an order and its order lines, into one data product.
• Domain Event Stream: split data driven by unrelated events, so fast-changing user tracking doesn't break your financial reporting.
• Cohesive Consumption: merge data that users always query together into one data product built around their needs.

Finding the right boundary is the biggest challenge in designing data products. There is no fixed checklist for it. But you don't have to reinvent the wheel: Domain-Driven Design and software engineering give teams concrete heuristics to discuss the trade-offs and decide.

"Finding the right boundary is the biggest challenge in designing data products. There is no fixed checklist for it. But you don't have to reinvent the wheel: Domain-Driven Design and software engineering give teams concrete heuristics to discuss the trade-offs and decide."

Tom De Wolf

---

Innovation Lead at ACA Group

Tom De WolfInnovation Lead at ACA Group

Beyond Domain-Driven Design

Tom also borrowed a few principles from software engineering:

• Multi-port: don't split a data product by technical format. Expose the same data through multiple output ports, such as Parquet, Iceberg or Kafka.
• Implementation hiding: keep intermediate transformation steps inside one data product, instead of exposing each step as a separate product.
• Single-team ownership: every data product has exactly one team that manages, evolves and runs it. Shared ownership is no ownership.

His conclusion: scoping is a design question with many dimensions. Shielding sensitive data, separating by rate of change and respecting what a team can carry all play a part.

Speakers and attendees of the third POA Summit in front of the DPG Media building.

How we help clients

At ACA Group, we help organisations put Data Mesh into practice: scoping data products, real domain ownership, a self-service data platform and lightweight governance with clear guardrails instead of a thick rulebook.

Read more

Data Mesh Live 2026: from principles to practice