1.1. Event sourcing
https://www.confluent.io/blog/apache-kafka-for-service-architectures/
Evenimentele ar trebui să conțină un ID unic, versiunea mesajului, versiunea schemei, numele serviciului emitent și datele.
O abordare uzuală pentru modificări incompatibile este crearea a două topicuri, orders-v1 și orders-v2, pentru mesajele cu schema veche, respectiv nouă. Dacă serviciul Orders este responsabil de comenzi, există câteva opțiuni:
Serviciul Orders poate publica simultan în ambele scheme.
Se poate adăuga un proces care convertește mesajele din orders-v2 în orders-v1. Pentru această conversie este folosit, de regulă, un job KStreams simplu.
Serviciile continuă să folosească ambele topicuri până la migrarea completă la v2. Atunci, topicul v1 poate fi arhivat sau șters, după caz.
O altă variantă combină un protocol fără stare, precum HTTP, cu o infrastructură de evenimente, de exemplu printr-un gateway. Fiecare serviciu poate expune două interfețe separate: una pentru evenimente și alta pentru cereri și răspunsuri. În acest model, schimbările de stare generează evenimente, iar interogările folosesc HTTP. Evenimentele reprezintă datele persistente ale sistemului, pentru care Kafka este potrivit; interogările sunt interacțiuni temporare, potrivite pentru HTTP. Materialul citat prezintă și alte modele de proiectare bazate pe evenimente.
1.2. Serviciile modulelor
Fiecare modul poate avea propriul microserviciu pentru implementarea logicii de business și separarea de celelalte module la actualizare. Secțiunea despre module oferă mai multe detalii.
Logica de business a unui modul poate fi accesată de alte microservicii pentru a evita apelurile API inutile.
Logica de business poate fi apelată direct sau prin API, când un serviciu este separat de baza de date.