Pular para o conteúdo principal

Kikwiflow

O que é​

O Kikwiflow é um motor de orquestração de processos de negócio — workflow / BPM — que roda embarcado: entra como uma dependência dentro do seu próprio app Java 21 + Spring Boot, sem um serviço externo para subir e manter à parte. Um processo é um grafo de passos descrito em JSON (.kikwi), desenhado visualmente no Kikwiflow Craft; a lógica de cada passo é uma classe Java comum, registrada como bean Spring. O Kikwiflow Monitor mostra cada instância em execução sobre o próprio diagrama.

Se você já quer pôr a mão na massa, o Início Rápido monta um processo real do zero em menos de 15 minutos. O resto desta página responde a pergunta que um arquiteto ou um tech lead faz antes de instalar qualquer coisa: por que isso existe?

O problema do sistema que ninguém entende mais​

Processos de negócio distribuídos crescem. Times crescem. E hoje, com geração de código acelerada por IA, código cresce mais rápido do que a capacidade de qualquer pessoa — humana ou não — de entendê-lo como um todo.

O resultado é um sistema que funciona — até não funcionar. E quando para, ninguém sabe exatamente onde no processo de negócio a falha aconteceu, quais instâncias foram afetadas, e o que cada uma carregava no momento da falha. Um incidente que deveria levar minutos para diagnosticar leva horas, porque a pergunta "o que estava acontecendo com o pedido #4471 às 14h32?" não tem uma resposta direta — só grep em logs espalhados por serviços diferentes, na esperança de reconstruir uma linha do tempo que devia estar visível o tempo todo.

Isso não é uma crítica a um time ou a uma linguagem. É o estado natural de sistemas distribuídos sem observabilidade de negócio — só que o problema fica maior, mais rápido, na proporção em que mais código é escrito por menos esforço humano por linha.

O problema do processo que vive fora do código​

A forma tradicional de resolver essa falta de visibilidade é criar uma camada separada: o processo é modelado em uma linguagem de modelagem própria, executado por um motor que opera como serviço externo, e o código da aplicação se conecta a esse motor via API.

Isso funciona. E tem um custo real: a lógica de negócio passa a morar em dois lugares. Quem desenvolve precisa aprender duas ferramentas — a linguagem de programação da aplicação, e a linguagem de modelagem do motor. Os testes automatizados cobrem o código, mas raramente cobrem o processo como um todo, porque o processo não é código — é uma definição interpretada por um sistema externo, com seu próprio ciclo de vida, sua própria forma de depurar, sua própria curva de aprendizado. Quando algo falha em produção, o stack trace aponta para dentro do motor, não para o seu código.

O que o Kikwiflow propõe​

A lógica do processo e a lógica de negócio vivem no mesmo lugar: no código Java que o time já escreve, nos testes que o time já roda, no repositório que o time já versiona. O motor embarcado cuida da orquestração, da persistência, das retentativas, dos timers — sem exigir que o time opere um serviço adicional. O Kikwiflow Monitor devolve a visibilidade que sistemas distribuídos perdem naturalmente: qual instância, em qual etapa, com quais variáveis, agora.

Isso não elimina a complexidade de orquestrar um processo de negócio distribuído — nenhuma ferramenta elimina. Mas move essa complexidade para dentro do lugar onde o seu time já sabe trabalhar bem: código Java, com tipagem, com testes, com breakpoint.

A diferença central: sem BPMN XML, sem expression language​

Filosofia central

Um processo é um grafo de nós descrito em JSON. A lógica de cada nó é uma classe Java comum, registrada como bean Spring. Não há expression language, não há scripting embutido, não há XML.

Na prática:

  • Uma tarefa executável não aponta para uma expressão — aponta para o nome de um bean Spring que implementa a interface TaskHandler. Você escreve handle(ExecutionContext execution) como escreveria qualquer outro componente Spring: injeção de dependência normal, testes com Mockito, breakpoints do seu jeito habitual.
  • Uma decisão em um gateway não é uma expressão booleana em uma string — é o retorno de um método resolve(EvaluationContext context) de uma classe Java comum, tão testável quanto qualquer outra classe de domínio.
  • Prazos de timer e políticas de retry seguem o mesmo padrão: interface Java pequena, implementação livre, resolução por nome de bean em tempo de execução.

O processo em si — a forma do grafo, quem chama quem — é modelado visualmente no Kikwiflow Craft e exportado como um arquivo .kikwi (JSON). A lógica de cada nó vive no seu código Java, no seu repositório, sob os mesmos testes e revisão de código do resto da aplicação.

Embarcado, não um serviço separado​

O Kikwiflow roda dentro da sua aplicação Spring Boot, como uma dependência Maven — não como um serviço externo que você precisa provisionar, versionar e manter disponível separadamente. O motor persiste o estado de cada instância de processo (MongoDB, hoje) e cuida de orquestração, retentativas e timers usando a própria capacidade de concorrência da sua aplicação, via threads virtuais.

O que você ganha​

  • Depuração normal. Um breakpoint em um TaskHandler é um breakpoint Java comum. O stack trace de uma falha em produção aponta para o seu código, não para dentro do motor.
  • Testes normais. Um handler é testável com JUnit e Mockito, sem subir infraestrutura. Ver Testando Seus Handlers.
  • Refatoração segura. Renomear uma classe, extrair um método, mover um pacote — a IDE acompanha, porque a lógica do processo é código Java de verdade, não uma string interpretada em tempo de execução.
  • Visibilidade operacional. O Kikwiflow Monitor mostra cada instância em execução sobre o próprio diagrama do processo, em tempo real, com capacidade de intervir diretamente (completar tarefas, retentar incidentes) sem tocar no banco.
  • Ferramentas em volta. Além do Craft e do Monitor, há uma extensão do VS Code para editar .kikwi junto do código e Agent Skills para modelar/documentar processos com um agente de IA.

Como diferentes pessoas no time olham para isso​

Desenvolvedor:

"Quero escrever a lógica de negócio como código Java normal, com testes normais, e ainda ter resiliência e observabilidade de graça."

Arquiteto:

"Quero que processos de negócio sejam rastreáveis, versionados, e não dependam de infraestrutura adicional para rodar."

Time de sustentação:

"Quando algo para em produção, quero saber exatamente qual instância, em qual etapa, com quais variáveis — e quero poder recuperar sem mexer no banco."

CTO / Tech Lead:

"Quero que a engenharia alinhe intenção, execução e resultado — e que isso seja visível, não uma suposição."

Além do guia​

Próximo passo​

Veja essas ideias funcionando em código real: o Início Rápido parte de um problema concreto — a abertura de conta digital de uma fintech — e monta esse processo do desenho no Craft até visível no Monitor. É o mesmo processo que o Guia do Desenvolvedor faz crescer, capítulo a capítulo. Para montar o pom.xml à mão ou entender a escolha de persistência, veja Instalação e Setup. Se esbarrar num termo em inglês, o Glossário reúne todos.