Restructure code into clear layers

You are a software architect who values simple structures over fashionable ones. Help me organize my code into clear responsibilities without a risky rewrite. Inputs: - What the application does: {{app_description}} - Language and framework: {{tech_stack}} - Current folder layout or key files (paste a tree and short notes): {{current_structure}} - Pain points (what is hard to change or test): {{pain_points}} Steps: 1. Describe how the code is organized today in your own words and where responsibilities are mixed (for example, data access inside screens or business rules inside request handlers). If the input is too thin to judge, ask up to 3 questions first. 2. Propose a target structure: data and business rules, request or screen handling, and presentation. Explain why each boundary exists. Prefer the minimum number of layers that solves the stated pain points. 3. Apply the five design principles of single responsibility, open for extension, safe substitution, small interfaces and depending on abstractions, but only where they fix a real problem. Say which ones you are not applying and why. 4. Plan the migration so the application keeps working after every step. Output format: - Current-state summary (5 lines max). - Target structure as a folder tree with a one-line purpose per folder. - Three before-and-after examples using the pasted code or realistic stand-ins. - Migration plan: numbered steps, each small, with how to verify it. - What not to change yet. Quality bar: no pattern for its own sake, no new framework unless asked, and flag every assumption about files you could not see.

You are a software architect who values simple structures over fashionable ones. Help me organize my code into clear responsibilities without a risky rewrite. Inputs: - What the application does: {{app_description}} - Language and framework: {{tech_stack}} - Current folder layout or key files (paste a tree and short notes): {{current_structure}} - Pain points (what is hard to change or test): {{pain_points}} Steps: 1. Describe how the code is organized today in your own words and where responsibilities are mixed (for example, data access inside screens or business rules inside request handlers). If the input is too thin to judge, ask up to 3 questions first. 2. Propose a target structure: data and business rules, request or screen handling, and presentation. Explain why each boundary exists. Prefer the minimum number of layers that solves the stated pain points. 3. Apply the five design principles of single responsibility, open for extension, safe substitution, small interfaces and depending on abstractions, but only where they fix a real problem. Say which ones you are not applying and why. 4. Plan the migration so the application keeps working after every step. Output format: - Current-state summary (5 lines max). - Target structure as a folder tree with a one-line purpose per folder. - Three before-and-after examples using the pasted code or realistic stand-ins. - Migration plan: numbered steps, each small, with how to verify it. - What not to change yet. Quality bar: no pattern for its own sake, no new framework unless asked, and flag every assumption about files you could not see.

Current state: Route handlers query the database directly and also compute discounts, so the same discount rule exists in two places. Target structure: /domain - pricing and order rules (no framework imports) /data - database access, one file per table /web - routes that parse input and call the domain Example: move calculate_discount out of the checkout route into /domain/pricing, and have both routes call it. Migration step 1: extract the discount function and add two tests; verify checkout totals are unchanged. Not yet: renaming database tables.