agentsclimarketplace

Data mesh and domain oriented design

Skill vaquarkhan/data-engineering-agent-skills/skills/data-mesh-and-domain-oriented-design

Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.

Install
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-mesh-and-domain-oriented-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Guides agents through domain-oriented data product and data mesh design. Use when organizing ownership, domain boundaries, federated governance, and shared platform responsibilities across multiple teams.

SKILL.md

2.7 KB, as published. Nobody here has run it

Data Mesh And Domain-Oriented Design

Overview

Use this skill when the problem is organizational scale as much as technical scale. It helps agents design domain-owned data products with explicit boundaries, interoperable contracts, and platform guardrails that do not collapse back into central bottlenecks.

When to Use

  • designing domain-oriented data products
  • defining ownership boundaries across multiple teams
  • introducing or refining a data mesh operating model
  • clarifying platform versus domain responsibilities
  • reducing central-team bottlenecks in large data organizations

Do not use this to rename ordinary pipelines as "data products" without ownership, contracts, or service expectations.

Workflow

  1. Identify domains and business boundaries. Clarify:

    • which team owns the source behavior
    • which team owns publish-ready data
    • where cross-domain dependencies exist

  2. Define data products, not just datasets. A data product should include:

    • owner
    • contract
    • consumers
    • freshness expectations
    • support and change path

  3. Separate domain ownership from platform ownership. Platform teams should provide capabilities, standards, and guardrails rather than own every dataset.

  4. Define federated governance rules. Include:

    • minimum contract rules
    • lineage requirements
    • discoverability
    • security and privacy baselines

  5. Check whether mesh adds real value. Not every small team or simple platform needs full mesh operating complexity.

Common Rationalizations

RationalizationReality
"We can call every table a data product."Without ownership and service expectations, it is just a dataset with better branding.
"Data mesh means no central standards."Federated governance still needs common interoperability rules.
"Each domain can optimize however it wants."Unbounded local choices make shared discovery, trust, and reuse much worse.

Red Flags

  • data products have no named owner
  • domain boundaries are driven only by org chart convenience
  • the platform team still owns operational details for every domain pipeline
  • governance standards are implied but not codified

Verification

  • Domain boundaries and ownership are explicit
  • Data products have contracts, consumers, and support expectations
  • Platform versus domain responsibilities are clearly separated
  • Federated governance rules exist for interoperability and trust

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.