Specifying an algebra, in the form of sealed case class hierarchies, to describe your program data domain, operations, and result conditions is a natural and common design pattern. But as your program does more, its algebra can become enormous and cumbersome. You will want to begin splitting your algebra into smaller domains to focus on specific concerns. By doing so you can reduce the scope of knowledge required to work in a given algebra, while building smaller, less monolithic interpreters. This talk goes through an example of designing a model for a realistic microservice, and then breaking it down into more discrete, focused concerns. Then we will use Cats Copproduct (with a mention to the Shapeless Coproduct) type to tie the separate algebras back together so the entire program can employ the capabilities of main different domains selectively. We will describe how this technique is also useful for stitching together different Free monad libraries when using the interpreter pattern. Finally we will talk about how this is one solution to the Expression Problem, but there are others out there.
