:PROPERTIES:
:ID:       4b24e03a-fa59-49e6-9e66-f0d4609b8a99
:END:
#+TITLE: Service Graph Oriented Programming
#+Author: Yann Esposito
#+Date: [2021-06-06]

- tags :: [[id:bec11f07-ffed-487b-9059-bdf6696548ab][programming]] [[id:d2a59fd6-947a-4ce5-9673-1494268678c0][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.

#+begin_src
foo-service-methods
  foo-do-a
  foo-do-b
  foo-do-c

def foo-service
  create-service( config-service, bar-service, baz-service)
#+end_src

The component will form an acyclic graph of dependencies.

Principles:

A service contain an internal state.
Again, every service has at most single instance for the entire Application.
Every method of the service can access this internal state.
No OOP is needed, only functions.

Ability to test isolated.
You can write:


#+begin_src
with-services-and-conf services conf
  test-the-services
#+end_src

Service is like an object in object oriented programming.
With some differences.
Services in your application should form a graph.
There is a dependency graph between your running services.

FooService:
  foo1
  foo2
  foo3

BarService:
  bar1
  bar2