A functional service isolates one responsibility behind a public functional interface. Clients can substitute its implementation transparently, whether it runs in the same process or separately. section 4.2
Use services to reduce coupling and clarify architectural layers. Keep the interface concise and minimal; external code should depend on it rather than bypassing it. section 4.2.1 section 4.3
A service-based design supports several practical choices:
- Split implementation into smaller sublayers while preserving larger boundaries between business logic, interfaces, and implementation. section 4.2.1
- Replace real external implementations with mocks or fakes so business logic can be tested in isolation. section 4.3
- Choose among service handles, type classes, ReaderT, GADTs, final tagless, and free monads according to coupling, convenience, boilerplate, and language-feature costs. section 4.3 section 13.2.7
Layering a hardware subsystem
An Hdl interface separates business logic from Device machinery, while service patterns divide the implementation layer into less-coupled hardware sublayers. A Service Handle can expose the boundary and allow tests to substitute a fake implementation. section 4.2.1 section 4.3
Figure 4.3 Layers and sublayers
Use the layer diagram to distinguish broad architectural layers from the smaller service-controlled sublayers inside implementation. section 4.2.1
