Data Architecture and Integration
Data Architecture and Integration tests how you model entities, own data, query it efficiently, and integrate without coupling. In ODC, entities live in modules, and public entities are a contract. Aggregates are the query mechanism; external entities represent data owned by another system. Integration uses REST or SOAP consumed through server actions, with structures as the contract.
Core rules
- Give every entity one writing module. Other modules read through public entities or actions, not direct writes.
- Choose deliberately between a real-time call and a local copy. A local copy needs a sync owner, a freshness target, and reconciliation.
- Design integrations contract-first and version them. Map external payloads to internal structures at the boundary.
- Make writes idempotent. Use a business key or idempotency key so retries do not duplicate orders or payments.
- Keep transactions local. Across systems, use compensating actions and eventual consistency rather than distributed transactions.
- Handle failure explicitly: timeout, retry with backoff, dead-letter path, and visible error state.
Worked example
A CRM owns customer data, but the ODC app needs fast customer search. Calling the CRM on every screen is chatty and fragile. The design stores a local Customer copy, synchronizes by timer or event, upserts by CRM ID, and records a last-synced timestamp. The screen searches the local aggregate; edits go through a CRM action, then trigger a refresh. Reasoning: search is read-heavy and tolerant of slight staleness; writes must remain authoritative in the CRM.
Traps
- Treating an external entity as a free local table without understanding latency and availability.
- Exposing internal surrogate keys to integration partners.
- Retrying non-idempotent operations and creating duplicates.
- Ignoring eventual consistency in user-facing workflows.