Business logic implements an application’s problem-domain rules and behavior. In a typical backend, entities model business concepts and preserve consistent state, while services coordinate more complex rules spanning one or more entities. Keep the rules close to the object they act on when possible; move a rule into its own class when it crosses objects or accumulates dependencies. section 1.4 section 2.3.1
The main design boundary is between business logic and infrastructure. SQL, HTTP calls, file access, third-party API structures, and similar communication details belong in thin infrastructure classes, not in classes that enforce domain rules. This keeps a change to storage, a web service, or a cache localized instead of spreading it through the domain. section 6.1 section 1.2.5
Isolating a cross-cutting rule
A complex feature that needs email-related collaborators and several repositories can become a dedicated service. Its constructor makes dependencies visible, its tests focus on one behavior, and callers can reuse it. But canceling an Enrollment belongs on Enrollment itself: separation should not push a rule away from the state it must keep consistent. section 2.3.1
Separate retrieval from rules as well. A rule tied to concrete database values becomes specialized and difficult to vary. Prefer a generalized rule that receives generic data, with a repository or small glue class retrieving concrete data and assembling the rule. Start with this understandable arrangement rather than prematurely pursuing maximum flexibility; revisit it if new variations make the glue code complex. section 5.2.1
Adding a cache without changing domain rules
An EmployeeRepository interface can keep employee lookup meaningful to its clients while HibernateEmployeeRepository contains database access. Adding a cache to findByLastName then changes the repository implementation alone. The boundary is valuable, but it should not erase useful infrastructure capabilities or pretend frameworks can be completely decoupled. section 6.1.4 section 6.6
This architecture diagram makes the intended boundary visible: domain classes hold business logic, while separate classes communicate with external systems and infrastructure. section 1.2.5
