Padrões funcionais e action terms

Um Service Domain tem nome, Control Record, operações e atributos. Dá para ler tudo isso e ainda não saber como ele se comporta. O padrão funcional resolve isso em uma palavra: ele diz qual é o ciclo de vida do Control Record. Se nasce e morre numa transação, se acumula por anos, se emite um veredito e encerra.

Pense no padrão como a classe base de que o domínio herda. Duas classes com a mesma base têm o mesmo esqueleto de operações, mesmo que uma trate de cartão e a outra de câmbio. É isso que torna o BIAN previsível para quem programa: dominou o esqueleto de Fulfill, entende qualquer domínio Fulfill em metade do tempo.

Três padrões confundem quem começa porque parecem a mesma coisa, "olhar dados". Não são. Track acumula lançamentos ao longo do tempo e mantém uma posição, como um extrato. Assess dá um veredito pontual sobre um caso e pronto, como um detector de metais. Analyse lê o histórico inteiro e devolve uma leitura, como a nutricionista com o diário alimentar na mão.

Se o seu sistema de fraude tem uma pontuação recalculada a cada evento e um perfil revisto por mês, você tem dois padrões diferentes e, quase sempre, dois domínios. Separar isso antes de desenhar a API poupa a refatoração que viria depois.

O padrão não é rótulo decorativo. Ele define que operações existem e que estado o Control Record carrega. Por isso trocar o padrão é uma mudança real, não cosmética.

Na v14 alguns domínios mudaram de padrão. O exemplo mais limpo é Legal Advisory, que saiu de Fulfill para Advise. A leitura é direta: antes o domínio era modelado como quem cumpre um acordo de prestação de serviço jurídico, agora é modelado como quem responde a uma consulta. O Control Record deixa de ser um arranjo de serviço e passa a ser uma sessão de aconselhamento, e as operações seguem essa troca.

No mapeamento isso tem um uso prático. Quando um sistema seu "não cabe" no domínio que parecia óbvio, teste o padrão antes de inventar domínio novo. Pergunte: o que o meu sistema guarda, acumula, encerra ou emite? Se acumula, procure um Track. Se emite veredito, um Assess. Se mantém um acordo vivo, um Fulfill ou um Agree Terms. Na maioria das vezes o domínio aparece, e o que parecia lacuna era só padrão errado.

Vale também para avaliar o que uma IA propõe: um mapeamento que coloca um sistema de posição de saldo num domínio Assess está errado pelo padrão, antes de qualquer discussão sobre nome. A aula 08 volta a isso com grounding nas definições oficiais.

Toda operação de um Service Domain é um action term aplicado a uma parte do Control Record: Initiate abre, Update altera, Retrieve lê. São 17 verbos, organizados em quatro famílias conforme o que tocam.

Governar o domínio: Activate, Configure e Feedback. Não mexem em registro nenhum. Ligam o domínio, ajustam parâmetros e recebem retorno sobre o serviço. É o painel de administração, não a transação.

Criar registro: Initiate, Create, Register, Evaluate e Provide. Cada um abre uma instância nova do Control Record. O verbo muda com o padrão: um domínio Fulfill inicia, um Catalog registra, um Assess avalia. Mesmo efeito, nasce um registro, verbo escolhido pelo ciclo de vida.

Agir sobre registro: Update, Control, Exchange, Capture, Execute, Request e Grant. Alteram um registro que já existe. Control suspende e retoma, Exchange aceita ou rejeita, Capture grava um evento vindo de fora, Execute roda uma etapa, Request pede uma ação, Grant concede.

Ler sem alterar: Retrieve e Notify. Devolvem estado ou avisam que algo mudou, sem mudar nada. O guia do BIAN cita CQRS ao separar leitura de escrita; para quem já separa command de query, é a mesma ideia levada à borda do serviço. Na implementação isso significa que Retrieve pode ser servido pela réplica de leitura e os outros quinze ficam no caminho transacional. Decidir isso cedo evita que a API de consulta herde o lock da API de escrita.