Separation of concerns
The principle that each part of your code should handle one kind of job, like showing the screen, applying business rules, or saving data, instead of mixing them.
A design principle that divides a program so each section addresses one distinct concern: presentation, business logic, data access, authentication. Mixing concerns, such as database queries inside UI components, makes code harder to change, test and reuse.
In a clinic, reception checks you in, nurses take vitals, doctors diagnose and the billing office sends invoices. If the doctor also ran billing, both jobs would suffer.
Agents told to "just make it work" often mix concerns: database calls in a button's code, pricing rules in an email template. Asking for separation keeps future changes small and testable.
The discount rules are currently inside the React component. For separation of concerns, I'll move them to src/pricing so the component only displays the result.
Keep separation of concerns: the component should only display data. Put the validation rules and the database calls in separate files.
Thinking it means one file per function or splitting everything into tiny pieces. It's about not mixing different kinds of jobs, not about file count.