Arquitetura orientada a eventos em Kotlin: de corrotinas a streams reativas

Arquitetura orientada a eventos em Kotlin: por que isso não é apenas uma tendência da moda

Imagine que sua aplicação é um mecanismo perfeitamente ajustado. Cada engrenagem sabe quando girar, cada pistão sabe quando se mover. Mas e se um dia for necessário adicionar uma nova peça sem parar toda a máquina? Na arquitetura síncrona tradicional, isso muitas vezes se torna um pesadelo: reescrever módulos inteiros, testar infinitas cadeias de chamadas e noites sem dormir.

É aqui que entra a arquitetura orientada a eventos em Kotlin — um paradigma onde os componentes se comunicam através de eventos, e não por chamadas diretas. Kotlin, com suas corrotinas e streams reativas, oferece ferramentas simplesmente ideais para isso. Neste artigo, não vamos apenas falar sobre teoria — vamos escrever código real, analisar Kotlin Flow e Channels, e mostrarei como construir um sistema flexível e escalável que não se desfaça na primeira carga de trabalho.

O que é arquitetura orientada a eventos em palavras simples

Na abordagem clássica (imagine microsserviços que se chamam via REST), cada requisição é uma conexão rígida. O Serviço A chama o Serviço B, espera a resposta, e se B cair — tudo quebra. Na arquitetura orientada a eventos é diferente: os componentes publicam eventos (por exemplo, "Pedido criado") e se inscrevem neles. Ninguém espera por ninguém, ninguém chama ninguém diretamente.

A beleza do Kotlin é que ele permite implementar esse modelo nativamente, sem a necessidade de frameworks pesados. As corrotinas fornecem threads leves, e Channel e Flow são barramentos prontos para eventos.

Vamos ver um exemplo simples — nosso próprio EventBus em Kotlin:

import kotlinx.coroutines.*\nimport kotlinx.coroutines.channels.*\n\nclass SimpleEventBus {\n    private val events = Channel<Any>(Channel.UNLIMITED)\n\n    suspend fun publish(event: Any) {\n        events.send(event)\n    }\n\n    suspend fun subscribe(handler: suspend (Any) -> Unit) {\n        for (event in events) {\n            handler(event)\n        }\n    }\n}\n\n// Uso\nfun main() = runBlocking {\n    val bus = SimpleEventBus()\n    \n    launch {\n        bus.subscribe { event ->\n            println("Evento recebido: $event")\n        }\n    }\n    \n    delay(100)\n    bus.publish("Olá, Event-Driven!")\n    delay(100)\n}

Este código é a base. Criamos um canal que funciona como uma fila assíncrona. O publicador coloca o evento, o assinante o pega. Tudo simples, mas já aqui se vê a força da arquitetura orientada a eventos em Kotlin: o assinante e o publicador não sabem nada um sobre o outro.

Kotlin Flow: streams reativas para eventos

Channel é ótimo, mas para projetos reais muitas vezes precisamos de mais: streams frios e quentes, transformações, tratamento de erros. É aqui que entra o Kotlin Flow — uma biblioteca reativa embutida diretamente na linguagem.

Flow é ideal para programação assíncrona em Kotlin, quando os eventos são gerados constantemente. Por exemplo, atualizações de taxas de câmbio, feeds de notícias ou estados de UI.

Streams frios vs quentes

É importante entender a diferença:

\n
• Stream frio (Cold Stream) — só começa a funcionar quando alguém se inscreve. Cada assinante recebe seu próprio fluxo de dados.
\n
• Stream quente (Hot Stream) — funciona constantemente, independentemente dos assinantes. Assinantes tardios perdem eventos antigos.
\n

Para arquitetura orientada a eventos, geralmente precisamos de streams quentes. Em Kotlin, eles são implementados via SharedFlow ou StateFlow.

Exemplo — sistema de notificações:

import kotlinx.coroutines.*\nimport kotlinx.coroutines.flow.*\n\ndata class Notification(val userId: String, val message: String)\n\nclass NotificationService {\n    private val _notifications = MutableSharedF