Modeling Business Processes and Domains

Full chapter covering the final major topic in MMA Book 1. Uses a fictional airline "Hellta" case study where brilliant engineers built a perfect lakehouse that produced nonsensical numbers -- because they never modeled the business processes or reconciled domain language.

Key concepts covered:

• Business process vs. domain: Process is horizontal flow (how work gets done); domain is a boundary of meaning (where language and rules are consistent)
• Bounded contexts (from DDD): Same term ("Customer," "On-Time Arrival") means different things across domains -- the data modeler must be the translator
• Ubiquitous language: Model vocabulary must match what stakeholders actually say
• Context collapse: When domain distinctions are flattened, data loses meaning -- catastrophic for AI vector search
• Tacit knowledge gap: Documentation captures only what's written; modelers must become "archaeologists" using gemba walks, artifact archaeology, and exception interviews
• EventStorming: Rapid collaborative modeling using sticky notes (Domain Events, Commands, Aggregates)

RDCO relevance

Core material for dbt consulting. The "Hellta" anti-pattern -- engineers building systems before understanding the business -- is exactly what we help clients avoid. The bounded-context and ubiquitous-language frameworks are directly applicable to semantic layer design. Cross-ref [[data-trust-ownership]] themes.