A service validates an order, calculates prices, writes to the database, sends email, and records analytics. How would you apply the single-responsibility principle without creating dozens of tiny classes?

In production I would also separate transactional work from effects that can fail independently. Saving an order and publishing its event may need an outbox, while email delivery can retry without repeating the order transition. I would watch the direction of change: if every pricing rule requires edits to the coordinator, the boundary is still wrong; if tracing one request requires opening twenty trivial files, it is over-split. Cohesion, failure ownership, and change history are better evidence than class size alone. I would refactor incrementally around repeated change pressure rather than designing a complete taxonomy of responsibilities in advance.