Hexagonal architecture vs Functional core / Imperative shell

There's been some comparison about theese two architectural styles recently. To me they address totally very different concerns and are by no means mutually exclusive. Let's review that visually.

Let's take the example of some user calling a rest-service with some request for modification. A typical application will have the workflow of 

• Validation 
• Load state from db 
• Compute new state
• Save state to db

Hexagonal architecture

I assume you have basic knowledge about this architecture. If not you might want to have a look at this. In this paradigm we'd distribute the steps of the given use case in the following way.

Inside the "hexagon" everything except what talks to the outside world

We have separated the blue parts from the yellow because those are the parts that talk to the outside world. The boundaries that we create by separating the repository from the rest are useful for testability (and a few other things that I won't go into in this post). We can test the whole logic by simply mocking the repository. So here the emphasis is on creating boundaries from the outside world. All the rest is considered inside the hexagon.

Functional core / imperative shell

In this paradigm we focus on what is pure and impure. A pure function is a function that needs nothing else than values as inputs and that does nothing else than returning a result. No side effects, no loading data from the file-system etc. A pure function always returns the same values given the same inputs. The properties of a pure function make them very nice to work with. For one thing they can be tested without any mocks, they don't surprise us, results can be cached(!) and so on. Because they have these nice properties we want to separate them from the rest, and possibly maximize the scope of them.

Let's look at the same application from the point of view of what is functional core and what is the imperative shell. 

The adapters and all the coordination logic is in the imperative shell. This shell delegates as much as possible to the functional core through calls to pure functions.

There is no change! The only difference is how we classify things. Admittedly this is because I already separated the pure parts from the rest. Note that the diagram is simplified in the sense that the validate and compute stages do not actually call the next stages. Both are pure functions that just return some value. 

Although in this case the architecture is both hexagonal and functional core / imperative shell, it is seldom the case. Often what we do in traditional applications is a lot of validation and computational logic in the middle of our service classes, just next to where we load and save state. Even worse we load state and save state in several steps with computational logic intermingled so there is very little to extract. 

Functional islands

What is called functional core is actually more like functional islands. It only makes sense if we can make them big enough so that at-least it makes sense to test them in isolation. That is, we tend to mould the architecture to increase the size of the functional islands. To get the most out of functional core we will tend to load everything beforehand and save everything afterwards, limiting the round-trips to the DB while risking loading data that is not used. One of the architectures that gives us the greatest opportunity for functional islands is EventSourcing, a though I detail here.

Personally I tend to extract pure functions a lot. It's easy to edge towards this in legacy apps and I find it a better trade-off for new apps because it makes testing a breeze, tests are blazing fast, they are easier to read without mocks and it is easier to write them in a manner that minimizes test maintenance. I tend not to do it when the islands are too small.

For more on this paradigm, here's a good collection of links. 

Conclusion

The two patterns are not mutually exclusive, in fact a lot of the goodness that both strive for is common, like testability and separation of concerns. As a result we get changeability.