Chapter 34 — Migrating an Existing Object-Oriented System¶

Start with one complete activity. Understand promised results, then identify participants, roles and behavior for explicit comparison with the old system.

Choose a Verifiable Business Line¶

Select clear inputs, durable results and failure rules, such as funding or payment. Preserve normal, rejection, duplicate and competition cases. Existing databases/interfaces can remain technical infrastructure.

The migration unit needs completion criteria. Moving a formula without actual settlement is calculation migration, not replacement of a transaction.

Identify Participating Identities from Classes¶

Read requirements and calls to separate User/Product duties by scenario. Identify buyer, payer, owner and fulfillment roles, players, borrowed and owned facts.

DTO fields are clues, not ready-made Roles. Reassess use, ownership and lifecycle; move technical keys and versions to application configuration.

Make Hidden Cooperation Visible¶

Identify access, qualification, calculation and persistence and establish atomic contracts. Place whole-activity order and boundaries in scenarios for review.

Pure calculation can migrate first with equal-input comparison, then facts, identity and settlement. Use independent expected results or historical evidence; copying a formula twice is not a correctness proof.

Control Deployment¶

Initially co-locate new services and existing adapters, limiting simultaneous changes to models, protocols and resources. Later split according to capacity and team ownership.

Data migration needs its own design for changed role, detail and snapshot structures. Decoding old records does not prove correct identity/ownership. Define authoritative writers during transition to avoid conflicting double writes.

Advance with Evidence¶

Retain versions, examples, durable outcomes and faults. Generation, local calculation, actual settlement and cross-process recovery represent different progress.

Completion returns to acceptance conditions: clear model, correct behavior, resources and operational recovery. Then new boundaries become maintainable system structure.

Part Contents · Full Book Contents · Previous Chapter · Next Chapter