Monolith to Modules: Boundary Mapping
Find natural seams in a large codebase before splitting it.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
Map boundaries in this codebase: [CODEBASE_DESCRIPTION]. Teams and ownership: [TEAMS]. Data model overview: [DATA_MODEL]. Pain points: [PAIN_POINTS]. Identify candidate modules by business capability, not by technical layer. For each, list responsibilities, data owned, inbound and outbound dependencies, change frequency and team ownership. Highlight shared tables and circular dependencies. Return a candidate table, a dependency matrix described in text, the three cleanest seams to start with, enforcement ideas such as dependency rules in the build, and the risks of splitting too early. Challenge whether a modular monolith would solve the pain without separate deployments. Provide a worked example of a dependency matrix for four candidate modules with invented counts of calls between them, and explain how to read it: heavy two-way traffic suggests the boundary is wrong. Add a table of change history: which files change together most often, found from version control, because modules should contain things that change together. Describe how to rehearse the split on paper before touching code, and how to agree the boundaries with the teams who will own them. Include an architecture decision record for the proposed boundaries and the review date. Add a plan for tests at module boundaries, such as contract tests, so teams can change internals without surprises. Describe the signals that the split is going badly: increasing cross-module changes, duplicated data, and slow builds. Provide a rollback option for each step until the boundaries are stable. Add an appendix listing five questions to ask each team about their module: what do you change most often, what do you wait for from others, what data do you need, who calls you, and what would you hide if you could. Use the answers to refine the map before any code moves. Add a note on measuring the result after the split: time to deploy, number of teams blocked per release, and incidents caused by changes in another module, compared with the figures before the split.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.