Cross-domain systems
On this page 9 topics
Overview
Topics
- Identity
- billing
- commerce
- data
- integration platforms
Learn first
4 h of practice (estimate)
Learning outcomes
- Identify cross-domain capabilities (identity, billing, commerce core, data, integration) and the coupling they create.
- Decide which cross-domain systems should be shared platforms and which should stay in domains.
- Design ownership and funding models for shared systems.
- Lead the evolution of a shared system without stalling its consumers.
Lessons
- 01Systems everyone depends on
- 02Identity, billing, and data as cross-domain capabilities
- 03Shared platform or domain-owned?
- 04Ownership and funding of shared systems
- 05Evolving a shared system safely
- 06Demo: untangling three competing customer-identity systems
- 07Demo: a funding model for the shared integration platform
Lab and exercises
Lab
STF-006-LAB1 · Cross-domain map
Outcomes: 1–4 · Time: ~3 h
- Map Platform 2.0's cross-domain systems (identity, billing, commerce core, data, integration) with consumers and coupling.
- Decide for each: shared platform or domain-owned, with reasons.
- Recommend an owner and a funding model for each shared system.
- Choose one duplicated capability and plan consolidation in steps with side-by-side running.
- Walk through the plan with role-played consumer teams.
Acceptance: consolidation plan keeps every consumer working at each step.
Exercises (case-based; six exercises)
| ID | Outcome | Task |
|---|---|---|
| STF-006-EX01 | 1 | From a call-and-data flow table, identify the five most depended-on systems and the teams each constrains. |
| STF-006-EX02 | 1 | Three teams keep their own customer address store. Describe the risks and who is affected. |
| STF-006-EX03 | 2 | Apply the shared-or-domain test to notifications, pricing rules, and customer identity; justify each. |
| STF-006-EX04 | 3 | Propose ownership and funding for a shared search service used by eight teams, with service levels. |
| STF-006-EX05 | 4 | Plan the migration of a shared API from v1 to v2 for 12 consumers without a big-bang cutover. |
| STF-006-EX06 | 4 | A consumer team says the migration clashes with its launch. Describe how you adjust the plan. |
Show solutions
- EX01 Rank by number of consumers and failure impact; typical: identity, commerce core, billing, data platform, integration.
- EX02 Divergent data, inconsistent privacy handling, duplicated fixes; affects checkout, support, marketing.
- EX03 Customer identity: shared platform. Notifications: shared platform if stable and common. Pricing rules: usually domain-owned, as they change with the business.
- EX04 One search team with on-call, an API, SLOs, a request process; fund centrally for core, chargeback only for heavy custom indexing.
- EX05 Version the API, run both, migrate willing consumers first, publish a timeline, offer help, retire v1 after the last consumer.
- EX06 Shift that team's window, keep v1 available longer, avoid blocking others.
Outcome coverage: all four outcomes are covered by the exercises and lab.
Workplace evidence: a cross-domain system whose ownership or design you changed.
Quiz
Outcomes: O1 cross-domain capabilities and coupling · O2 shared versus domain-owned · O3 ownership and funding · O4 evolving shared systems.
A self-check for you: nothing is graded, saved or sent anywhere. Choose an answer, then check it. You can try again as often as you like.
Practical part
Six case exercises STF-006-EX01 to EX06 plus the lab, defended as a recommendation to role-played consumers. Pass: at least five of six exercises correct, quiz at least 8/10, and a consolidation plan that keeps every consumer working at each step.
Common mistakes
"shared" systems with no owner; consolidating by decree; ignoring the consumers' roadmaps.
Assessment
Recommendation defense.
Workplace evidence
A cross-domain system whose ownership or design you changed.
Career relevance
Enterprise systems integration (ARC-032) and identity architecture (ARC-017).