From 38481c4c245d3f2b46d09aac361b649e46b69049 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Thu, 26 Dec 2019 11:31:23 -0300 Subject: [PATCH] Added note about CQRS --- content/code/microservices-artifact-input-state.md | 10 ++++++++++ content/code/microservices-artifact-input-state.pt.md | 8 ++++++++ 2 files changed, 18 insertions(+) diff --git a/content/code/microservices-artifact-input-state.md b/content/code/microservices-artifact-input-state.md index 6c16bb1..5784f4d 100644 --- a/content/code/microservices-artifact-input-state.md +++ b/content/code/microservices-artifact-input-state.md @@ -44,6 +44,14 @@ updated or displayed, so it doesn't need constant updates; and so on. Each one of those is a different microservice, because each one of those is a different artifact. +Just to be clear: our artifacts are kept in a Firestore database, which our +clients query directly, most of the time receiving the real time notifications +for changes. But another way to keep those artifacts is to have separate +services, which the clients would query -- which is really akin to what CQRS +describes (well, that is, if your microservice receive commands to change the +data, that is; I won't claim them to be CQRS if your microservices are dealing +with events directly.) + Alright, if those are artifacts, where does "state" gets into this? The state is the amount of information a microservice has to keep in order to build the artifact. For example, in the narration, each time a new narration comes in, @@ -87,3 +95,5 @@ This change in the my way of thinking about microservices design help me rethink the way we are building our microservices at work, and it is also helping me rethink some things on a personal project (which I hope to finish and show it next year). + + diff --git a/content/code/microservices-artifact-input-state.pt.md b/content/code/microservices-artifact-input-state.pt.md index 11e196a..ed31a7c 100644 --- a/content/code/microservices-artifact-input-state.pt.md +++ b/content/code/microservices-artifact-input-state.pt.md @@ -46,6 +46,14 @@ e por isso não precisam de atualizações visuais constantes; e assim por diante. Cada um desses é um microserviço diferente, porque cada um desses é um artefato diferente. +Para clarificação: nossos artefatos são mantidos em um banco Firestore, que os +clientes fazem as requisições diretamente, mas que na maior parte do tempo vão +simplesmente receber as notificações de alteração dos dados. Mas outra forma +de manter esses dados é ter serviços separados, que responde às requisições +dos clientes -- que é bem próximo da forma que CQRS é descrito (bom, quer +dizer, seria CQRS se o microserviço recebesse comandos; eu não vou dizer que +são CQRS se o microserviço estão lidando com eventos diretamente). + Bom, se esses são os artefatos, onde é que o "estado" entra nessa história? O estado é o conjunto de informações que o microserviço precisa ter para produzir o artefato. Por exemplo, na narração, cada vez que uma nova narração