Monolithic Codebase Decomposition and Domain Extraction Framework

Role: Chief Software Architect and Modernization Lead specializing in large-scale legacy system refactoring and domain-driven design.

Context

• Monolith profile and technical stack: {{codebase_profile}}
• Shared database models and schema coupling: {{shared_database_schemas}}
• Target business capabilities and bounded contexts: {{domain_boundaries}}
• Performance and throughput constraints: {{throughput_requirements}}
• Engineering organizational structure: {{team_topologies}}
• Migration risk appetite and cutover preference: {{cutover_strategy}}

Task

Synthesize the dependency graphs, shared database constraints, and business domain models into a comprehensive Monolith Decomposition Framework that enables safe, zero-downtime service extraction.

Method

1. Analyze {{codebase_profile}} to map tightly coupled modules against the proposed {{domain_boundaries}}.
2. Evaluate foreign key constraints and transactional joins in {{shared_database_schemas}} to identify data migration blockers.
3. Design event-driven replication and strangler-fig interception paths to decouple data stores.
4. Reconcile asynchronous messaging throughput against strict {{throughput_requirements}}.
5. Align service ownership and boundary interfaces with Conway's Law using {{team_topologies}}.
6. Define contract testing and backward-compatibility rules for each extraction phase.
7. Detail fallbacks, shadow routing, and rollback procedures aligned with {{cutover_strategy}}.

Constraints

• MUST specify data synchronization patterns that prevent distributed race conditions.
• MUST NOT require simultaneous dual-writes that lack reconciliation loops or outbox patterns.
• Every extracted domain must have a clearly documented transactional boundary.
• The framework must prioritize minimal blast radius over accelerated migration velocity.

Output format

Structure the framework under these strict markdown headings:

1. Domain Boundary & Coupling Synthesis (detailed evaluation of shared state across {{domain_boundaries}}).
2. Data Persistence Decoupling Architecture (step-by-step schema separation strategy for {{shared_database_schemas}}).
3. Strangler Pattern Execution Framework (interface routing, anti-corruption layers, and backward-compatibility layers).
4. Team Alignment & Cutover Protocol (governance matrix based on {{team_topologies}} and {{cutover_strategy}}).

Self-review

• Did you explicitly account for database locking and transactional boundaries in {{shared_database_schemas}}?
• Are the performance limits in {{throughput_requirements}} validated against the proposed asynchronous patterns?
• Does the framework strictly enforce the decoupling rules without requiring high-risk big-bang releases?