Service Oriented Programming

tags: programming architecture
source

This is a presentation of a design pattern to architecture a big source code. The focus of this paradigm is composability (which is superior to modularity from my perspective).

This focus on improving locality of impact. If you change a file, it should has most impact locally in the same "service-block". And could have an impact on transitively dependant "service-blocks".

First, this focus on functions. There will be no global variable. There are two kind of functions in programming, pure and impure functions.

A great deal is made about state management and purity. From a high level perspective:

lib/ contain only pure functions (YES!)
services/ contain all services

Important every service can have at most ONE running instance. This is probably the most controversial choice about this architecture.

The services directory will contain "sub-project"/"modules". Every service should have the following structure:

src/
- service the service declaration
- core the implementation of the function in the service, should contain pure functions
- schemas/types the metas structures (data format mostly)
- routes if you service is a web service, routes declarations
test/
- service_test the service test
- core_test the tests for pure functions

A service should be considered as a function returning a record of functions.

foo-service-methods
  foo-do-a
  foo-do-b
  foo-do-c

def foo-service
  create-service( config-service, bar-service, baz-service)

The component will form an acyclic graph of dependencies.

Principles:

A service contain an internal state. Every method of the service can access this internal state. No OOP is needed, only functions.

Ability to test isolated. You can write:

with-services-and-conf services conf
  test-the-services

2 KiB Raw Blame History

Service Oriented Programming

2 KiB

Raw Blame History