data-mesh-and-domain-oriented-design

Name: data-mesh-and-domain-oriented-design
Author: vaquarkhan

19stars4forks

How to install data-mesh-and-domain-oriented-design?

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

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

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Data Mesh And Domain-Oriented Design
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- designing domain-oriented data products
10	- defining ownership boundaries across multiple teams
11	- introducing or refining a data mesh operating model
12	- clarifying platform versus domain responsibilities
13	- reducing central-team bottlenecks in large data organizations
14
15	Do not use this to rename ordinary pipelines as "data products" without ownership, contracts, or service expectations.
16
17	## Workflow
18
19	1. Identify domains and business boundaries.
20	Clarify:
21	- which team owns the source behavior
22	- which team owns publish-ready data
23	- where cross-domain dependencies exist
24
25	2. Define data products, not just datasets.
26	A data product should include:
27	- owner
28	- contract
29	- consumers
30	- freshness expectations
31	- support and change path
32
33	3. Separate domain ownership from platform ownership.
34	Platform teams should provide capabilities, standards, and guardrails rather than own every dataset.
35
36	4. Define federated governance rules.
37	Include:
38	- minimum contract rules
39	- lineage requirements
40	- discoverability
41	- security and privacy baselines
42
43	5. Check whether mesh adds real value.
44	Not every small team or simple platform needs full mesh operating complexity.
45
46	## Common Rationalizations
47
48	\| Rationalization \| Reality \|
49	\| --- \| --- \|
50	\| "We can call every table a data product." \| Without ownership and service expectations, it is just a dataset with better branding. \|
51	\| "Data mesh means no central standards." \| Federated governance still needs common interoperability rules. \|
52	\| "Each domain can optimize however it wants." \| Unbounded local choices make shared discovery, trust, and reuse much worse. \|
53
54	## Red Flags
55
56	- data products have no named owner
57	- domain boundaries are driven only by org chart convenience
58	- the platform team still owns operational details for every domain pipeline
59	- governance standards are implied but not codified
60
61	## Verification
62
63	- [ ] Domain boundaries and ownership are explicit
64	- [ ] Data products have contracts, consumers, and support expectations
65	- [ ] Platform versus domain responsibilities are clearly separated
66	- [ ] Federated governance rules exist for interoperability and trust

People who liked this also viewed

6 picks

Type

data-mesh-and-domain-oriented-design

19stars4forks

View on GitHub

How to install data-mesh-and-domain-oriented-design?

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

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Data Mesh And Domain-Oriented Design
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- designing domain-oriented data products
10	- defining ownership boundaries across multiple teams
11	- introducing or refining a data mesh operating model
12	- clarifying platform versus domain responsibilities
13	- reducing central-team bottlenecks in large data organizations
14
15	Do not use this to rename ordinary pipelines as "data products" without ownership, contracts, or service expectations.
16
17	## Workflow
18
19	1. Identify domains and business boundaries.
20	Clarify:
21	- which team owns the source behavior
22	- which team owns publish-ready data
23	- where cross-domain dependencies exist
24
25	2. Define data products, not just datasets.
26	A data product should include:
27	- owner
28	- contract
29	- consumers
30	- freshness expectations
31	- support and change path
32
33	3. Separate domain ownership from platform ownership.
34	Platform teams should provide capabilities, standards, and guardrails rather than own every dataset.
35
36	4. Define federated governance rules.
37	Include:
38	- minimum contract rules
39	- lineage requirements
40	- discoverability
41	- security and privacy baselines
42
43	5. Check whether mesh adds real value.
44	Not every small team or simple platform needs full mesh operating complexity.
45
46	## Common Rationalizations
47
48	\| Rationalization \| Reality \|
49	\| --- \| --- \|
50	\| "We can call every table a data product." \| Without ownership and service expectations, it is just a dataset with better branding. \|
51	\| "Data mesh means no central standards." \| Federated governance still needs common interoperability rules. \|
52	\| "Each domain can optimize however it wants." \| Unbounded local choices make shared discovery, trust, and reuse much worse. \|
53
54	## Red Flags
55
56	- data products have no named owner
57	- domain boundaries are driven only by org chart convenience
58	- the platform team still owns operational details for every domain pipeline
59	- governance standards are implied but not codified
60
61	## Verification
62
63	- [ ] Domain boundaries and ownership are explicit
64	- [ ] Data products have contracts, consumers, and support expectations
65	- [ ] Platform versus domain responsibilities are clearly separated
66	- [ ] Federated governance rules exist for interoperability and trust

People who liked this also viewed

6 picks

Type