Business logic is the domain rules and processes that decide how an application responds to meaningful situations. It describes what the application does—such as assembling a sandwich, reporting a meteor, or retrieving an astronomical object—rather than the mechanics of databases, HTTP servers, files, or logging. In a free-monadic design, these scenarios are explicit programs built from domain-oriented interfaces. section 14.0 section 7.1.1
A useful boundary separates business behavior from operational details. The behavior may request capabilities through interfaces, while interpreters perform the actual effects and hold operational state. An application layer then assembles the scenario, interpreters, state, and startup work. This keeps responsibilities distinct without pretending that the layers can run independently. section 7.1.1 section 3.2.3
Keep business logic focused by distinguishing it from nearby concerns:
- Put decisions and domain workflows in the business scenario; keep persistence, interoperability, presentation, and operational state in their respective layers. section 7.1.1
- Depend on detail-free interfaces, not concrete implementations. Interfaces decouple business logic even when only one implementation currently exists, and they improve testability. section 10.1.1
- Avoid placing domain behavior directly in a web handler. Handler code tied to bare IO and server concerns is easier to break and harder to test. section 14.2.2
- Treat dependency-injection choices as architectural trade-offs. Some approaches can couple business logic to implementation environments or force configuration details into its API. section 13.2.6 section 13.2.7
Moving a database lookup out of an HTTP handler
A direct HTTP handler opens a database connection and issues a query itself. A layered alternative expresses getObject' as an AppL scenario that requests database functionality through the application framework. The Servant-side handler supplies the runtime and runs that scenario, leaving HTTP error handling and environment access at the edge. The domain-aware lookup no longer depends directly on Handler or connection setup. section 14.2.2
Figure 14.6 A layered web service application
The layer diagram clarifies why the HTTP server and effect interpreters remain at the boundary while domain-aware work is moved into the application scenario. section 14.2.2
The boundary is architectural rather than purely commercial: code that defines how an organization operates is business logic, but the same label can also include auxiliary code placed in the framework’s free-monadic environment. The goal is to make important behavior explicit, high-level, controlled, and protected from subsystem details. section 14.0 section 13.2.7
This separation also supports production concerns. Logging can be invoked through a logger interface without embedding console or file details in a scenario. STM can enter the framework through an interface, giving business logic a state-handling mechanism while implementation code provides safe concurrency. The same principle applies whether the boundary is database, network, logger, or concurrent state. section 10.1.1 section 9.3
