Harmonic Slicing

The aim is to implement a mechanism to maintain the code per context, per logic suitable for event-driven architecture.

Play this article
  • License: CC BY for Article, MIT for Code Repos

  • Last revision: Apr 20 2021

  • Target Language(s): Rust, C#, Go, Typescript

  • Audience: Engineers (refer to academic perception via the paper series)

Introduction

The aim is to implement a mechanism to maintain the code per context, per logic suitable for event-driven architecture, while we keep the slate harmonic between immutability and mutability by leveraging the power of FP and OOP!

Concerns

  • To isolate idempotent logic with a robust application tier/layer in place.

  • To achieve better threading flow.

  • Leverage the mutability implication of OOP to tier our application.

  • Leverage the immutable flow for static algorithmic snippets by the power of FP.

  • CQRS in nature.

  • DDD centric.

What do we mean by a Slice of Logic

Simply the Request tunnel originated by a Command or Query to retrieve a response from the application layer will shape our Slice of Logic.

Thread Selectors for better threading flow:

Selectors select a slice of logic and handle the thread by generating a command or a query. For instance, each microservices entry layer has a background service holding the selectors.

Selectors are responsible to assign strongly typed command/query models through command/query shaper to comply with CQRS intuitively.

Behaviour(s)

The Pipeline Pattern is the heart of the Harmonic Slicing Approach, and within every sequence of the operations, pipeline will be leveraged for below behaviour(s):

  1. When we only watch inbound, e.g. LoggingBahviour

  2. When we watch inbound / outbound, e.g. PerformanceBehaviour

  3. When we watch inbound / outbound and its interruption during operation, e.g. UnhandeledExceptionBehaviour

  4. When we watch inbound and its interruption before actual operation, e.g. ValidationBehaviour

OOP and FP in Harmony

FP encourages immutability and purity as much as possible, while OO is built for state and mutation – a slightly organized version of imperative programming. Objects can be immutable, but OO seems to imply state/change.

On the other hand, OO is robust in polymorphic behaviour while it keeps the state of the object mutable.

The aim is to leverage OOP to tier our code for the sake of better abstraction, encapsulation and polymorphic behaviour, while we apply FP at the tail to code algorithmic scenarios. In this scenario, the Bridge snippet will carry the structured data in a mutable way.

FP Bridge

The bridge is a static snippet that moves the structured data from the handler to the FP ground.