FDE Foundations · Module 4: Software Craft
Data Models for Integrations
Integration code fails at the seams: identifier mismatches, timezone drift, and schema drift. A canonical model with explicit mapping tables prevents all three.
11 min reading
Objectives
- Design a canonical internal model
- Map external identifiers explicitly and store them
- Handle timestamps and timezones without regret
Canonical model
Define one internal representation per entity: your own invoice, order, or ticket object with typed fields. Every external system maps into it on the way in, and out of it on the way back. Without the canonical model, each new integration multiplies pairwise conversions; with it, each integration is one mapper.
Identifiers
Store the external identifiers: the source system's ID, its revision or updated-at, and a unique key for idempotent writes. When reconciliation questions arrive, and they will, the mapping table answers them in one query instead of an archaeology project.
Timestamps
Store UTC instants everywhere, convert at the presentation edge, and record the source timezone when the source sends local times. The classic failure: a batch window that "works until the clocks change" in October.
Drift
External schemas change. Keep a schema version per source, validate on ingest, and fail loudly with a quarantine path rather than silently coercing wrong data into the canonical model. A row that cannot map should be parked with its payload, not dropped with a log line nobody reads.
Quick check
An optional 2-3 question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Exercise
Model the canonical invoice object for a two-source integration (email PDFs and an ERP export): field list with types, the external identifier fields you store, and your timestamp strategy.
Pass criteria
Field list with types, explicit external ID and updated-at fields per source, and UTC storage with a stated conversion point and source-timezone handling.