88 lines
2.4 KiB
Org Mode
88 lines
2.4 KiB
Org Mode
: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
|