Event Storming

É uma técnica que entra na parte estratégica/conceitual do DDD.
Com o Event Storming é possível ter um entendimento muito mais profundo do domínio.
É uma técnica para entender de forma mais clara o domínio das aplicações através dos eventos gerados por elas.
Geralmente ocorre em formato de workshop entre a área técnica e os domain experts. É comum que se use post-its e faça presencialmente mas existem alternativas para que seja realizada remotamente.
O Event Storming não é a única forma de buscar essa clareza mas ele busca ser mais dinâmico.

Mapeamento dos eventos

A ideia é entender o que o sistema faz com base em seus eventos.
Domain Events
- Verbo no passado, algo que já aconteceu
- Relevante para os domain experts
- Todo evento pode ter um post-it de uma cor específica.

Destacar mais os eventos que indicam finalização de uma parte relevante da aplicação. Dessa forma fica fácil distinguir entre eventos pequenos e grandes

Entender quem são os atores ajuda a saber quem deve participar do Event Storming, quais Domain experts devem ser envolvidos

Há momentos em que decisões precisam ser tomadas com base em algum dado.
- Onde e como esse dado é obtido não é importante nesse momento. Essa é uma complexidade acidental, não de negócio.

A chave para pensar em políticas é "Sempre que" (Whenever). A política (policy) descreve algo que deve acontecer com base em um gatilho.
Pode ser automatizada ou manual.

Os eventos podem ter diversas origens:
- A ação de um usuário
- Gerado por sistema externo
- Por tempo
- Consequência de outro evento (por meio de uma policy)

Alguns eventos podem conectar áreas diferentes. Esses são eventos pivô, servem de transição entre as áreas.
Isso pode nos ajudar a perceber contextos delimitados.
Não existe fórmula mágica para delimitação dos contextos, mas algumas coisas podem ser observadas como indicação de mudança de contexto:
- Palavras diferentes sendo usadas com o mesmo significado
- Palavras iguais sendo usadas com significados diferentes
- Quando sistemas diferentes estão "observando" o mesmo evento.
Mesmo seguindo várias técnicas, sempre podemos encontrar áreas cinzentas, onde não há clareza de qual área é responsável pelo quê e nem todos estão na mesma página.
Essas áreas cinzentas podem trazer muita discussão até que os impasses sejam resolvidos. Mas é importante observar que tudo isso acontece antes que qualquer código seja desenvolvido para que esses problemas não sejam encontrados no meio do processo de desenvolvimento.
É importante observar, também, as novas ideias e oportunidades, além dos possíveis riscos e pontos que precisam ser revisados.

Às vezes, nem todos vão chegar num consenso nas tomadas de decisão. Nesses momentos, uma possibilidade para resolver o impasse é utilizar votação.
Quem está conduzindo o workshop deve ter muito cuidado para fazer a votação de forma a manter o clima leve.

A divisão de contextos pode ser um ponto de partida para divisão em microsserviços