From f157e9377b83040fefe78d613f2169c35390978d Mon Sep 17 00:00:00 2001
From: trilero <trile@riseup.net>
Date: Fri, 12 Apr 2024 14:54:06 +0200
Subject: [PATCH] [Docs][WIP] Starting some arch guidelines, so far for
 personal usage

---
 doc/coding-style-guide.md | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 doc/coding-style-guide.md

diff --git a/doc/coding-style-guide.md b/doc/coding-style-guide.md
new file mode 100644
index 0000000..a68ccd1
--- /dev/null
+++ b/doc/coding-style-guide.md
@@ -0,0 +1,35 @@
+# Coding style guide
+
+# Architecture & Responsibilities
+
+## (P2P) Listeners
+
++ Responsible for taking the message, sending the processing order and replying to the request
++ Processing the message might imply sending other messages over the pub/subs, but the listener only knows about its own channel and sticks to that one.
+
+
+## (Redis) Listeners
+
++ Responsible for taking the message, sending the processing order and sending the next message in the stream.
++ Processing the message might imply sending other messages over the pub/subs, but the listener only knows about its own channel and sticks to that one.
+
+
+## Services
+
++ Calls to clients/repos/end of pipe.
++ Retries
++ Error handling
++ Logging on debug level
+
+
+## Listeners & Publishers
+
++ Direct communication? It's okay both on Redis & P2P when it's about their own channel/topic.
++ Listeners should not hold logic/knowledge over how the messages are internally processed.
+
+
+## Commands
+
++ They should represent an action. Not a reaction on a event.
++ If I have a check in message, the action is "Process Check in message".
++ They should be granular and have a 1:1 relation with each input type. For instance, a listener and a http endpoint might call the same command handler, but they should have the same semantic meaning & purpose.
\ No newline at end of file
-- 
GitLab