Browse Source

Merge branch 'hotfix/20191226.1'

master 20191226.1
Julio Biason 5 years ago
parent
commit
80616f8527
  1. 10
      content/code/microservices-artifact-input-state.md
  2. 8
      content/code/microservices-artifact-input-state.pt.md

10
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 of those is a different microservice, because each one of those is a different
artifact. 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 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 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, 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 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 helping me rethink some things on a personal project (which I hope to finish
and show it next year). and show it next year).

8
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 diante. Cada um desses é um microserviço diferente, porque cada um desses é um
artefato diferente. 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 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 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 produzir o artefato. Por exemplo, na narração, cada vez que uma nova narração

Loading…
Cancel
Save