Designing APIs using System, Process, and Experience Layers12% of the exam
Enterprise and Bounded Context Models
Choose model scope from shared meanings and ownership, then preserve explicit interchange boundaries where contexts differ. Keep the model useful through hands-on collaboration between domain experts, modelers and implementers.
Recommend the use of an Enterprise Data Model or Bounded Context Data Models based on a set of APIs and specific preferences and organizational characteristics.
~7 min read · 7 practice questions
What the exam expects
- Select a shared enterprise model or bounded-context models from organizational semantics.
- Avoid equating API count with the number of domain models.
- Preserve application independence and explicit translation boundaries.
- Organize reusable core definitions and scoped industry extensions.
An enterprise data model provides common business definitions across its agreed enterprise scope; a bounded context bounds a model's applicability; an interchange language carries information between models; translation relates representations; a vertical extension adds industry-specific types around reusable core definitions.
Key facts
Enterprise scope
- Detail
- Common meanings and workable shared ownership support a common model.
Context scope
- Detail
- Different valid models can communicate without becoming identical.
- Source
- DDD (opens in a new tab)
API count
- Detail
- Endpoint count alone does not define model boundaries.
- Source
- DDD (opens in a new tab)
Application independence
- Detail
- A vendor's detailed native schema is not automatically a canonical enterprise model.
- Source
- CIM (opens in a new tab)
Core and extension
- Detail
- Industry libraries can extend or aggregate reusable core definitions.
- Source
- CIM (opens in a new tab)
Published Language
- Detail
- Document an interchange and translate each internal model.
- Source
- DDD (opens in a new tab)
Unusual consumer
- Detail
- A one-off translator can preserve a coherent shared protocol.
- Source
- DDD (opens in a new tab)
Separate Ways
- Detail
- Avoid integration where no significant relationship warrants it.
- Source
- DDD (opens in a new tab)
Hands-on modeling
- Detail
- Technical model contributors spend some time touching implementation.
- Source
- DDD (opens in a new tab)
Domain refactoring
- Detail
- New business insight can motivate iterative model refinement.
- Source
- DDD (opens in a new tab)
Sources for this section (2)
- Why can isolating a technical modeler from implementation produce an impractical model?
- When a new domain insight motivates refactoring, what collaboration supports the iterative refinement?
- How can a rigid division between experienced designers and implementers hinder model-driven development?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the MuleSoft Platform Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 47 lessons of the MuleSoft Platform Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Practice exams purchase adds inline bank questions and topic practice (7 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Choose guide-only, practice-only, or save $4 with both