# Application-as-a-Function Thinking

DevFeed: [Application-as-a-Function Thinking](<https://devfeed.tech/articles/application-as-a-function-thinking-26037.md>)

Original publisher: [Read original article](<http://doridori.github.io//Architecture-Application-as-a-Function/>)

Author: SystemDotRun

Published: 2022-10-11T00:00:00Z

Content type: article

Language: en

Sources: [SystemDotRun](<https://devfeed.tech/sources/systemdotrun.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Code](<https://devfeed.tech/topics/code.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Requirements](<https://devfeed.tech/topics/requirements.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [race-condition](<https://devfeed.tech/topics/race-condition.md>), [event driven](<https://devfeed.tech/topics/event-driven.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [event-driven](<https://devfeed.tech/tags/event-driven.md>), [oop](<https://devfeed.tech/tags/oop.md>), [productivity](<https://devfeed.tech/tags/productivity.md>), [race-condition](<https://devfeed.tech/tags/race-condition.md>), [requirements](<https://devfeed.tech/tags/requirements.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

The article argues that placing a stateless pure function at the core of an application, within a functional-core imperative-shell architecture, can simplify testing and reduce complexity. It discusses how scattered requirements, weak documentation, poor tests, naming problems, race-prone object-oriented state, low cohesion, and event handling can make systems harder to understand and maintain.

## Source excerpt

TL;DR Architecting an application with a pure function at its core can be a first step towards the "functional-core imperative shell" ideal, which can simplify testing and lower an applications complexity bar. Why? Simplification. As a novel alternative to KISS, we start with a quote from The Grug Brained Developer: complexity very, very bad And for completeness: Complexity: a measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it For many applications the challenge is how to simply & correctly represent a large number of domain requirements in code, and how to raise the complexity-bar sufficently to enable a high degree of engineer productivity & runtime stability . A low complexity-bar reduces the amount of time it takes for a developer to get to the brain-meltdown-event-horizon-like state after which completion of new work slows down expontentially due to sheer codebase and test suite complexity which results in low grokability (i.e. code which is hard to understand or follow), an increasing degree of emergent behaviour, a higher probability of introducing regressions and generally, just slow development. A high complexity-bar conversely allows a desired order and serenity to take hold and more time spent on adding value as opposed to fire-fighting. I have observed different reasons for a low complexity bar, including: Domain requirements being spread throughout all codebase components Non-existent / incomplete / disorganised domain requirements documentation A non-existent / disorganised / bloated / poorly performing test suite Poor naming Race condition rich OOP state manipulations Low architectural cohesion across a codebase / team In addition if your application is highly event driven (user input / network / OS / peripherals / sensors) not having a simple approach to process incoming events can lead to chaotic code. Multiply this if you are working within a sensitive domain which has strict requirem