← Mon, Sep 21 digest

Deterministic Core, Non-Deterministic Shell

read article ↗ hn thread ↗

summary

Software reliability increases when developers separate business logic into a deterministic core and external interactions into a non-deterministic shell. While functional purity is one way to achieve this, any code that consistently produces the same output for the same input is sufficient for high testability. This separation allows complex logic to be tested without mocks or stubs, making the system easier to maintain and verify. By treating determinism as the primary goal, this architectural pattern becomes applicable to a wider range of languages and legacy systems.

key points

  1. Determinism is a broader and more practical requirement than functional purity because it includes state machines that produce repeatable results despite being imperative.
  2. Non-deterministic elements such as network calls, random number generators, and system clocks should be pushed to the outer shell to keep the core logic isolated.
  3. Legacy codebases can be improved through the 'defragmentation of determinism,' which involves identifying and grouping existing deterministic logic to shrink the surface area of hard-to-test code.

who should read it

Software engineers and architects who want to improve their testing strategies and reduce the complexity of maintaining legacy codebases.

discussion positive

consensus

Commenters agree that the 'functional core, imperative shell' pattern is primarily a strategy for improving testability. By isolating impure side effects like network requests into a shell, developers can keep business logic in a pure core where the same inputs consistently produce the same outputs. This separation simplifies the testing process and allows complex logic to be verified independently of external dependencies.

top insight

The discussion on randomized algorithms suggests that deterministic behavior should not be strictly defined as producing the same output every time. Instead, algorithms like randomized quicksort or treaps can be considered functionally valid for a core if their outputs maintain statistical guarantees, regardless of whether they are seeded or produce different internal structures.

Generated by an LLM from the article and thread. Check the sources before relying on it.