Sap Commerce Refactor

SAP Commerce Refactor

Overview

Use this skill to refactor SAP Commerce backend modules without redesigning behavior.

Keep service implementations orchestration-focused and move reusable stateless logic into cohesive utility classes.

Trigger Checklist

Use this skill when one or more are true:

• refactoring SAP Commerce service/facade implementation classes
• spotting duplicated stateless helper methods across implementations
• replacing repeated literals with constants
• improving JavaDoc coverage on public interfaces and methods
• adding tests for extracted deterministic logic

Out Of Scope

Do not use this skill for:

• storefront/frontend redesign work
• net-new architecture or broad redesign
• extension scaffolding or framework primers
• workflows that require schema or wiring changes not needed by the refactor scope

Progressive Disclosure

Load only what the task needs:

• references/refactor-workflow.md for execution sequence and boundaries
• references/extraction-catalog.md for helper grouping patterns and class placement
• references/gotchas.md for high-frequency refactor failure modes
• references/report-template.md for concise delivery reporting

Workflow

1. Inspect the target package and identify duplicated deterministic helpers.
2. Keep orchestration in services; extract stateless logic into util classes grouped by concern.
3. Replace repeated literals with constants in an existing or newly scoped constants class.
4. Keep compatibility with existing Spring wiring and public contracts.
5. Improve JavaDoc on public interfaces and interface methods.
6. Add or update unit tests for extracted helper logic.
7. When tests are in scope, add or update unit tests to cover extracted and refactored logic, then run the project's standard test and coverage commands.
8. Verify behavior parity and report changes and residual risks.

Non-Negotiable Rules

• Preserve runtime behavior unless fixing an obvious defect.
• Do not move methods that depend on injected collaborators, persistence, transactions, or external integrations.
• Keep utility classes final with private constructors and static methods.
• Keep service classes slim and focused on flow coordination.
• Use constants for repeated metadata keys, statuses, parameter names, and event strings.
• Use restrictive visibility and remove dead helper code after extraction.
• Use protected getters for injected dependencies and call those getters internally when aligned with module style.

Completion Output

At completion, report:

• extracted helper groups and their destination classes
• logic intentionally left in services and why
• constants introduced or consolidated
• JavaDoc updates performed
• tests added/updated and execution evidence
• explicit behavior-parity statement and any remaining risks