A software has many stakeholders and each of those stakeholders may request changes to it.
For example an invoicing application has several stakeholders:
- The database administrator who is responsible about how the invoice data are stored
- The Chief Operations Officer (COO) that gives the legal requirements about how each item is taxed, and how discounts are calculated
- The accountant that decides how the data should be laid out in the invoice report printed
The aim of the Single Responsibility Principle is to help you from braking something of stakeholder B when making a change requested by stakeholder A. Single responsibility means that each class must be accountable to only one person (or better, role) in the company.
The last thing you want to do is have the COO yell at you for breaking how the tax is calculated, while migrating to a different db schema or while changing the layout of the report that the accountant asked you to.
Now, specifically for the invoice case in your example, the BCE model would recommend that you make a distinction between application agnostic logic, and application specific logic. An Invoice is a business (aka domain) object. This object might as well be used by other applications within the company that have to do with invoices. Methods such as addItem(), removeItem() belong to the invoice class (which is a business object) since they are use-case agnostic. Now, code with regards to some specific use-case, belongs to another class known as the controller (or interactor). I would say that calculating charges is part of the billing use-case and would probably put it separately. This is subjective, since one may also claim that that those rules are not specific to that one application or use-case.