Functional Architecture Is Better

Wittgen­stein wrote, “The limits of my language mean the limits of my world.”

Moritz Nähr, Public domain, via Wikimedia Commons

And functional architecture works best with functional programming languages.

Functional Software Architecture (“FUNAR”) is one of the most advanced curricula in the iSAQB Advanced canon. It’s about the specific techniques for domain modelling and struc­turing software systems that functional programming enables.  These are signif­i­cantly different from the convential techniques available in object-oriented architecture, and lead to signif­icant improve­ments of important architecture quality metrics: They reduce coupling and complexity, the resulting models are more supple, and it is signif­i­cantly easier to establish correctness.

How does functional architecture do this?  The three most important factors are:

• immutable data
• powerful abstrac­tions
• algebra

What does all that mean specifically?

Immutable data means that the program does not alter objects after creation. There are no “setter methods”. At first, this sounds like a painful restriction compared to OO, not really like a feature: After all, changing objects is pretty much the basis for object-oriented programming. How can you model state without changing objects?

It turns out to be quite simple: In a functional architecture, when a new state comes into effect, the program does not mutate the object repre­senting the state. Instead, it just creates a new one. The old one stays as it was, basically a memory of the past. Conse­quently, in functional programming, objects repre­senting state are a kind of snapshot.

Not changing objects in place has many concrete advantages:

• The output of a function is solely deter­mined by its input: This makes it much easier to document its behavior, and strengthens the explanatory power of type signatures.
• Such functions are much easier to test than OO methods that change state, and that might need “setup” and “teardown”.
• Implicit depen­dencies through global state are greatly reduced, which leads to a reduction in coupling of an order of magnitude.
• Functions in the software corre­spond to mathe­matical functions and thus enable the use of mathe­matical reasoning – more about that later.
• In concurrent programs, it is not necessary to perform expensive and hard-to-get-right synchro­nization to access shared state.

If you find this unintu­itive, you might be pleas­antly surprised how easy this is in practice, and how close it is to the way human perception works – make snapshots instead of using setter methods to destroy the past.

(OO experts might argue that it’s a well-known and good OO practice to use “value objects” – i. e. immutable ones. Indeed!)

Powerful abstrac­tions means that functional programming enables abstrac­tions at a higher level than OO does.  Some of those universal abstrac­tions already made their way to OO languages, like the map method on collec­tions. Those, however, are only the tip of an iceberg of libraries with abstract useful ideas. OO languages have acquired many functional features (“lambda”), but their usage is still often clunky and cumbersome compared to real FP languages – and that makes those FP abstrac­tions less useful there.

Abstraction is generally something that happens more often in functional architecture than in OO, even and especially when it comes to concrete domains. Functional languages are more uniform than their OO counter­parts, and this makes abstraction in functional architecture more systematic. As a result, it goes wrong only rarely.

This “systematic abstraction” is additionally supported through the avail­ability of mathe­matical concepts, specif­i­cally from algebra.

Many domain models exhibit properties that algebra has catalogued and inves­ti­gated for hundreds of years. (Some people shun the use of mathe­matics in software devel­opment. That’s really a shame, as math was the method of choice for formally modelling the world around us before there were computers. It has yielded invaluable experience and insights.) Indeed, mathe­matical concepts such as “monoid” or “functor” often yield fresh domain insights.

Moreover, the transition from such models to veritable domain-specific languages is fluid.

Another important difference: Functional architecture is code, and constructing it does not require using an inter­me­diate notation. This is also enabled by the improved expres­siveness of functional languages, which makes the “bird’s-eye view” of the architecture directly apparent.

Functional architecture really is a different world, and it’s quite daunting for a three-day training. Conse­quently, you should bring (in addition to some curiosity) some basic knowledge of functional programming.  But don’t worry, open FUNAR trainings usually come with a one-day “pre-training” that will provide that knowledge. If you’re open for the challenge, you’ll come back with many insights, some which are also directly applicable in an object-oriented setting. A good example is domain modelling using combi­nators. The training also provides a bridge to Domain-Driven Design, which works even better with FP than with OO.

Completing the training gets you 10 credit points for compe­tence in method­ology and 20 credit points for compe­tence in technology. We’re looking forward to seeing you at FUNAR!