Testability and self-containment of business logic.

If we find that it is difficult to test our business logic, the unit tests have to have some mock-up code, something is wrong with the implementation. In my view, all the business can be performed manually; it is just a matter of how slow it is, how inefficient it is without relying on technology. Even big data analysis can be performed by just paper and pencil, it is just very slow, not scalable. With all that being said, business logic does not HAVE to depend on anything, not UI, not database, not service location, not data delivery mechanism, just nothing. It is complete, self-contained, and fully testable w/o the need for anything.

The data processing logic(the business logic), data fetching(not business logic) and data updating(not business logic) are different concerns. Once those things are mixed together, we would have to mock up DB calls/service calls, which is a clear indicator of NOT separating the concerns. The separation of concerns can be manifested at all different levels - system, service, component, class, and method.

Some list of different concerns:

functional vs non-functional

Stable logic and versatile logic, static vs dynamic

Data vs presentation

Data vs data structure

Event vs method

Who vs when

Behavior vs sequence of behaviors(flow or orchestration/collaboration)

Fetch data vs update data

Distributed vs localized.

Employing separation of concerns would lead to fewer interactions across boundaries and less complexity. SoC also gives us different dimensions of software - space dimension, time dimension, data dimension, etc. Eventually, it gives us a clear structure, leads to maintainable, and understandable software.