B · Business understanding and domain modeling

Model evolution

Keeping history, migrating, and staying compatible when rules change.

Classification boundary

Include: Include versioning, migration, compatibility, and history when rules, schemas, or data models change.

Choose a neighboring leaf when: Use the corresponding B model leaf for designing a new model and D for coordinating migration execution.

This capability may appear in standards across different stages. Explore stage expectations

24 questions

Choose a group based on the evidence you need. Groups follow existing question formats, not difficulty or mandatory prerequisites. Each batch has up to eight questions.

Judgment and options24

Compare goals, constraints, options, and trade-offs.

Questions 1–8

A producer plans to rename a field and change an enum’s meaning, while a dozen teams depend on the current schema. How would you manage the change?
An order has a single status field that means both fulfillment progress and payment result, and several teams read it. How would you split it into two concepts and move old data and old consumers over smoothly?
A service changes eligibility from “current account status” to “account status at application time plus a risk-review result.” Support needs to explain historical denials, and audit must reproduce the original decision. How would you evolve rules and data models without conflating old and new outcomes?
Duplicate registration created two customer entities later confirmed to be the same company. Reports should unify them, while contracts, approvals, permissions, and personal actions must retain original responsibility. How would you model the merge?
A support ticket can be reopened when a customer provides new evidence and may be split into follow-up work. How would you model states and events so closure, reopening, and splitting remain traceable?
A business rule is corrected retroactively. Reports need corrected results, while decision-makers also need the results available at the time. How would you manage both historical views?
A producer adds an order status, and an old consumer rejects the whole message because enum validation is strict. Teams disagree over who must update, and consumers have different owners. How would you design compatibility and rollout order?
The commercial rule for a service changes from a free trial to a refund after conditions are met, while historical orders were signed under the old terms. How would you evolve the model and workflow so both old and new transactions remain explainable?

Questions 9–16

A supplier API replaces one “delivered” status with “dispatched” and “received,” but historical data has no basis for distinguishing them. How would you update the domain model, external contract, and related reporting?
A database field has been replaced, but reports, exports, and external integrations still read it; deleting it directly could cause silent errors. How would you plan compatibility migration, consumer confirmation, and final removal?
Billing changes from calendar-month pricing to service-day pricing, with the new rule applying only to new contracts; old contracts cross the release date, and support still needs to explain past invoices. How would you version rules, contract applicability, and invoice snapshots?
Business categories may be added, merged, or renamed. Reports must reproduce the definition used at the time and compare results under the current definition. How would you preserve source categories, mapping versions, and report definitions?
An event producer wants to change a field from a string to a structured object, but some consumers deploy slowly and others drop unknown fields when writing records back. How would you stage dual writes, version negotiation, migration, and retirement of the old format?
A customer-ownership field in historical events is wrong and must be corrected in bulk to recompute downstream metrics; the same events may also trigger notifications and partner callbacks. How would you separate data recomputation from side-effect replay?
A new workflow requires every record to have an ownership field, but historical data lacks it and older clients still write records. How would you design backfill provenance, dual-read/write migration, validation gates, and retirement of old clients?
The system changes its user key from email to an immutable ID, but mobile caches, partner callbacks, and historical exports still reference email. How would you design mappings, a dual-read period, privacy cleanup, and retirement of old references?

Questions 17–24

The team wants to move eligibility checks from service code to a configurable rules engine so Operations can adjust them; many historical exceptions exist and execution order is implicit in code. How would you discover rules, verify semantic equivalence, and govern configuration access?
An early consumer deduplicates only by order ID, but one order can have several legitimate changes; the key must include an event version and historical messages need replay. How would you migrate keys without losing or duplicating processing?
A customer entity must be split into two real customers after an erroneous merge, while old orders, permissions, and metrics reference the original ID. How would you model the split, historical attribution, current-reference migration, and indeterminate records?
Several teams define user-status events differently, and the platform plans to unify them; some consumers rely on special meanings in old fields and cannot migrate at once. How would you build compatibility adapters, parallel validation, and deprecation governance?
A product changes permanently valid credits to monthly refreshes, but some older contracts promise permanent balances and users have accumulated unused credits. How would you version rules, balance lots, contract cutovers, and user explanations?
A new model requires additional features and changes the meaning of existing ones, while online serving must still support rollback to the old model. How would you version feature contracts, deployment order, dual-read cost, and retirement criteria?
Orders, inventory, and loyalty points are owned by separate services; messages may be duplicated, reordered, or delayed. How would you define event identity, idempotency boundaries, and compensation records?
A product line splits into two business units. Old orders belong to the previous organization, while future orders use the new structure. How would you represent organization versions and historical views?

Back to the whole domain