This repository demonstrates some of the concept's used by Jet's Order Management System to abstract the concerns of connecting to and interacting with infrastructure components using F#. It should not be treated as production-ready code. Instead, use it as a guide for how to build a similar abstraction layer.

To learn more about the concepts in this example repo, please read the following articles:

• Abstracting IO using F#
• F# Microservice Patterns
• Scaling Microservices
• Observability Using Abstracted IO

This code should not be used in production and is for demo/sample purposes only. Please see SECURITY.md for information on reporting security concerns.

The OMS.Infrastructure project is a demonstration of how to abstract away common I/O concerns using concepts from Domain Driven Design, and the Repository Pattern.

Quite simply, target infrastructure is distilled down to a string URI.

let uri = "kafka://kafa-brokers/some-topic?someOption=true

The URI describes the target infrastructure, and the library uses this string to generate an object known as a Stream Definition. The Stream Definition can then be used to access the infrastructure for reads and writes.

Ex:

let sd = uri |> Service.parse
let result = Inputs.read sd
metch result with
| Choice1Of2 ReadResult.Found events -> () // content is available
| Choiec2Of2 ReadResult.NotFound -> () // no content was found

The Inputs and Outputs modules use a common data structure called the Domain Event, which wraps the data read, or data written as a byte array.

ex:

let data = events |> List.map (fun e -> e |> deserializeFromBytes<MyData>)

All read and write operations handle logging and metric writing in a consistent manner. There is no need for any infrastructure adapter to implement this logic. It only needs to return the data that was reqeusted of it.

ex:

module OMS.Infrastructure.Inputs

let read (sd:StreamDefinition) =
    // start by return a read result for the appropriate Stream Definition
    readForSd sd
    |> Async.retry
    |> Async.Catch
    |> Logging.logException
    |> Metrics.recordLatency

Lastly, the generalized details for the microservice pattern used with this repository are also described in the Service.fs file.

Microservices were treated as stream processors following the Single Responsibility Principle. Messages arriving at the microservice are processed and a side effect is generated as an output. There are three main components of the pipeline:

decode (deserialize message) -> handle (apply business logic) -> interpret (execute side-effect)

Example setup of a microservice

let handler = Service.processInput log "MicroServiceName" handle interpret

incomingStreamDefinitionUri
|> Service.parse lookup
|> Service.consume 
|> Service.decode microserviceDecoder
|> Service.handle log handler
|> Service.start

These interfaces and patterns were used to reduce the complexity of the OMS code base and made the parlance of interacting with infrastructure simple, concise, and easy to learn.

OMS.Infrastructure

Microservice