Designing APIs using System, Process, and Experience Layers12% of the exam
System API Models and Backend Isolation
Choose a System API representation from the required abstraction and existing contracts. Preserve business semantics and identifier perspectives while using model-driven design to keep the agreed model useful in implementation.
Recommend the most appropriate approach relating the API data model of System APIs to that of their backend system based on specific requirements and organizational characteristics.
~7 min read · 6 practice questions
What the exam expects
- Select a System API model from business requirements and agreed boundaries.
- Distinguish business objects from physical database structures.
- Place translation where the required contract is implemented.
- Preserve identifier meanings and adaptable coded-value representations.
A backend model describes a source system's representation; an API model describes the exposed representation; a canonical model supplies an agreed independent vocabulary; a local identifier belongs to one system; a global identifier identifies an entity across the synchronization design.
Key facts
Customized instances
- Detail
- A System contract can hide their differences through mapping.
- Source
- SAP (opens in a new tab)
Relational storage
- Detail
- Reframe tables into required business-domain objects.
Business validation
- Detail
- Capability owners validate a bottom-up reframe and required channels.
Existing System contracts
- Detail
- Process conversion can preserve backend-specific interfaces below a canonical Process contract.
Process identity
- Detail
- Global identity is the documented CIM Process perspective.
- Source
- CIM (opens in a new tab)
Target identity
- Detail
- System
idfollows the target system perspective. - Source
- CIM (opens in a new tab)
External identity
- Detail
- Retain the global value separately when the target supports it.
- Source
- CIM (opens in a new tab)
Mutable code list
- Detail
- A string can avoid freezing a backend-owned catalog in the schema.
- Source
- CIM (opens in a new tab)
Model refinement
- Detail
- Revisit the model for natural implementation and domain insight.
- Source
- DDD (opens in a new tab)
Shared language
- Detail
- Carry refined concepts through conversation, diagrams and code.
- Source
- DDD (opens in a new tab)
- Why is a divide between model analysis and software design harmful?
- When the team's model language changes, which implementation names should follow it?
- Which collaborative modeling technique lets a team test whether its vocabulary expresses an interaction clearly?
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 (6 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