Aligning With Business Domains

Who this is for

Data Architects, Platform Engineers, Analytics Engineers, and Tech Leads who need to design data platforms and models that mirror how the business actually works.

Prerequisites

• Basic understanding of business capabilities and value streams (how your company delivers value).
• Familiarity with data modeling concepts (entities, events, dimensions).
• Awareness of Domain-Driven Design terms (domains, bounded contexts) is helpful but not required.

Why this matters

Real tasks you will face as a Data Architect:

• Designing domain-owned data products that enable self-serve analytics without central bottlenecks.
• Reducing cross-team dependencies by drawing clear boundaries (who owns which data, where contracts live).
• Translating business capabilities (e.g., Order-to-Cash) into pipelines, storage layouts, schemas, and SLAs.
• Prioritizing platform features that unlock the most impactful business domains first.

Concept explained simply

Aligning with business domains means structuring your data architecture around how the business creates value. Rather than building technology-centric pipelines, you map data products to business capabilities and their bounded contexts. Each domain owns its data and publishes it with clear contracts so others can safely consume it.

Mental model

Use the path: Business capability map → Domains → Bounded contexts → Events and entities → Data products → Pipelines and contracts → Governance.

• Capabilities clarify purpose (what value is delivered).
• Domains and bounded contexts clarify language and ownership.
• Events/entities clarify what data should exist and why.
• Data products and contracts clarify how value is shared safely.

Worked examples

E-commerce: Order-to-Cash

• Domains: Catalog, Pricing, Ordering, Payments, Fulfillment, Customer Service.
• Bounded contexts: In Payments, Authorization vs Settlement; in Ordering, Cart vs Order Management.
• Data products:
  • Ordering.OrderFacts (daily): order_id, customer_id, status, total_amount, created_at; SLA: 30 min; Owner: Ordering team.
  • Payments.SettlementLedger (hourly): payment_id, order_id, method, amount_settled, settlement_date; SLA: 1 hour; Owner: Payments team.
  • Fulfillment.ShipmentEvents (stream): order_id, package_id, event_type, event_ts; SLA: near-real-time; Owner: Fulfillment team.
• Outcome: Finance can reconcile revenue using OrderFacts + SettlementLedger, while CX tracks delivery via ShipmentEvents—no central bottleneck.

Healthcare provider: Appointments and Claims

• Domains: Scheduling, Clinical, Billing, Claims.
• Bounded contexts: Claims Intake, Adjudication.
• Data products:
  • Scheduling.AppointmentSchedule (15 min): appointment_id, patient_id, provider_id, status, start_ts; PHI controls applied; Owner: Scheduling.
  • Claims.AdjudicationResults (daily): claim_id, status, reason_code, adjudicated_amount; Owner: Claims.
• Outcome: Operations sees no-show rates by provider. Finance tracks denial reasons by payer. Governance ensures PHI masking where needed.

Subscription media: Growth analytics

• Domains: Marketing, Growth, Payments, Content, Streaming.
• Bounded contexts: Growth Activation vs Retention.
• Data products:
  • Growth.ActivationFunnel (daily): user_id, step, step_ts; Owner: Growth.
  • Payments.SubscriptionStatus (hourly): user_id, plan, renewal_dt, status; Owner: Payments.
  • Content.ViewEvents (stream): user_id, content_id, watched_seconds; Owner: Streaming.
• Outcome: Product can correlate activation and retention without asking central data to stitch bespoke pipelines each time.

Step-by-step playbook

1. Map capabilities and domains: list top value streams (e.g., Acquire → Convert → Retain) and key domains.
2. Identify bounded contexts per domain: where language and data models change meaningfully.
3. List core events and entities: e.g., OrderPlaced, PaymentSettled, ShipmentDelivered; define essential attributes.
4. Design data products per bounded context: define purpose, schema, refresh cadence, and owner.
5. Write the contract: schema, SLA, quality SLOs, versioning, retention, privacy rules, deprecation path.
6. Connect sources to products: pick patterns (CDC, events, batch) that suit the domain’s latency and stability needs.
7. Add governance guardrails: catalog entries, ownership in metadata, access controls, data quality monitors.
8. Pilot with one domain: ship one end-to-end domain product, measure time-to-insight and rework rate.

Exercises

Complete these before the quick test. Your answers do not require external tools—plain text is fine.

Common mistakes and how to self-check

• Mixing contexts: stuffing multiple meanings into one table (e.g., "status" meaning different things). Self-check: can two teams read the same field the same way?
• Ownerless data products: nobody maintains the contract. Self-check: is an on-call name listed?
• Tech-first boundaries: organizing data by tools (e.g., one big CDC lake) rather than business value. Self-check: can you point to which capability it serves?
• Hidden semantics: schemas without definitions. Self-check: definitions exist and are reviewed by business owners.
• Underpowered SLAs: best-effort refresh leads to brittle dashboards. Self-check: do consumers know freshness expectations?

Practical projects

• One-domain pilot: Pick one domain (e.g., Ordering). Deliver one gold data product with full contract and monitoring. Success metric: a consuming team ships a production dashboard using it within two weeks.
• Capability-to-product catalog: Build a lightweight catalog page listing capabilities → domains → data products, including owners and SLAs. Success metric: every product has an owner and a support contact.
• Contract-driven pipeline: Implement a pipeline that validates schema and quality SLOs before publishing. Success metric: broken changes are caught before consumers.

Learning path

1. Understand business capabilities and domains (this lesson).
2. Model domain events and entities.
3. Design domain data products and write contracts.
4. Implement pipelines with governance and quality checks.
5. Measure outcomes and iterate: time-to-insight, rework rate, and defect rate.

Mini challenge

Pick any product you use (e.g., ride-sharing). In 20 minutes, list three domains and one data product per domain with owner, schema (5–7 fields), and a freshness SLA. Then write one risk if the contract is missing.

Next steps

• Finish the two exercises below.
• Take the quick test at the end of this page. The test is available to everyone; sign in to save your progress.
• Schedule a 60-minute workshop with one domain team to draft a real contract.

Exercises — full instructions

Exercise 1: Domain-to-data-product mapping

Scenario: FreshMeals, a meal delivery app. Domains: Marketing, Menu Management, Ordering, Delivery, Customer Support, Finance.

• Task: Identify 3–4 bounded contexts and propose 4 data products. For each, specify owner, schema (6–10 fields), refresh SLA, key consumers, and one quality SLO.
• Constraint: At least one streaming product for operational visibility; at least one batch product for analytics.

Exercise 2: Write a data product contract

Scenario: Payments domain. Product: Payments.SettlementLedger.

• Task: Write a one-page contract covering: purpose, schema (fields + rules), freshness SLA, quality SLOs, privacy classification, retention, versioning, and deprecation.
• Constraint: Include at least two validation rules and one PII masking rule.

Quick Test

When you finish the exercises, take the quick test below to check your understanding. The test is available to everyone; sign in to save your progress and resume later.