Blog

Oseias 12 relembra a história de Jacó, aquele de quem nasceu o próprio Israel. Antes de existir uma nação, existiu um homem. E a história desse homem ajuda a entender o povo que veio depois.

Jacó não foi um patriarca perfeito. Sua história começou marcada pela conduta nem sempre honesta. Mas em determinado momento algo mudou. Jacó lutou com Deus, confrontou sua própria história e saiu daquele encontro transformado. Foi ali que Jacó se tornou Israel.

O contraste com o povo do tempo de Oseias é evidente. Enquanto Jacó passou pela transformação, a nação parecia repetir apenas a parte antiga da história, antes do duelo.

O capítulo fala de comércio injusto e balanças desonestas. Prosperidade construída sobre astúcia. Como se habilidade para negociar fosse suficiente.

O texto deixa claro que não existe separação entre espiritualidade e vida prática. O problema espiritual aparece nas relações, nos negócios e nas decisões diárias.

A balança injusta não é apenas um erro econômico. É reflexo de um coração desalinhado.

A história de Jacó aparece então como espelho. Ele também tentou garantir a vida pela astúcia. Mas em algum momento parou de fugir e entrou na luta.

E foi nesse confronto com Deus que veio a transformação.

Oseias 12 sugere que o mesmo caminho continua aberto. A luta nunca foi o problema. O problema é fugir dela.

Porque é nesse encontro que o homem deixa de viver apenas pela astúcia de Jacó e começa, finalmente, a viver como Israel.

Nem todo projeto de TI é adequado para DDD. Concordo.

Há sistemas cuja complexidade está na engenharia, não no domínio. Compiladores, bancos de dados, motores estatísticos. Nesses casos, o desafio central é técnico.

Agora, outro argumento que sempre aparece: “Se é só CRUD, não faz sentido usar DDD.” Com esse, eu não concordo tão facilmente.

Foi exatamente essa discussão que tive com meus alunos em um workshop recente. E ela expõe um erro de critério que condena sistemas com potencial de riqueza à anemia.

Quando alguém diz “é só CRUD”, está olhando para a interface. Uma tela, alguns campos, um botão de salvar. É um critério visual.

Mas arquitetura não se decide pela aparência da tela. Se decide pela natureza das mudanças.

A pergunta correta não é “quais campos precisamos?”, mas “quais são os motivos que levam esses dados a mudar?”.

Entender esses motivos permite desenhar um ciclo de atualização saudável. Modelar transições, não apenas estados.

Um cadastro de funcionários com salários ilustra bem.

Salário não muda ao sabor de um clique. Em acordos coletivos, a movimentação acontece em lote. Em promoções, segue critérios.

Se você modela apenas como “editar salário”, organiza o sistema em torno da operação técnica, não do processo que justifica a mudança.

CRUD organiza software por operação. Domínio organiza software por significado.

CRUD pensa em registro isolado. Domínio pensa em transição de estado e evento que dispara consequência.

E esse entendimento começa ao questionar o motivo da mudança em cada campo.

Nome muda por casamento ou decisão judicial. Salário muda por promoção ou acordo coletivo. Cargo muda por reestruturação. Cada campo carrega uma história possível.

Quando você modela a história, o sistema ganha estrutura. Quando modela só o campo, nasce anêmico.

É assim que surgem eventos de domínio.

“SalárioReajustadoPorDissidio”.

“FuncionarioPromovido”.

“NomeAlteradoPorDecisaoJudicial”.

Eles dão semântica ao que ocorre. Muito diferente de um espião no banco que grita quando uma coluna muda.

O banco enxerga alteração. O domínio enxerga transformação com contexto.

Aceitar cedo demais que “é só CRUD” é uma decisão infeliz.

Você estrutura o sistema em torno de operações técnicas. Quando surgem reajustes coletivos, histórico, auditoria ou novas regras, o modelo começa a ranger.

A lógica se espalha. A manutenção encarece. O usuário sente fricção.

Não é o tamanho do sistema que define a necessidade de DDD. É a natureza das suas mudanças.

Se há história, há domínio. E onde há domínio, reduzir tudo a update de campo é abrir mão de estrutura antes mesmo de começar.

Oseias 11 é um dos capítulos mais íntimos do livro. Deus não fala como juiz. Fala como pai. Ele lembra que chamou Israel desde o Egito. Que ensinou o povo a andar. Que o sustentou quando ainda era frágil.

A relação não começou ontem. Foi construída no tempo. Isso muda o peso da infidelidade. Não é uma quebra pontual de regra. É afastamento de uma história inteira de cuidado. Deus investiu presença. O povo respondeu com distância.

O capítulo chega ao seu ponto mais forte quando Deus declara que seu coração se comove. Há juízo anunciado, mas também há tensão interna. Não é frieza. Não é impulso. É conflito entre justiça e compaixão. E a compaixão não nasce de sentimentalismo. Nasce de fidelidade à promessa feita muito antes.

Há consequência. Há disciplina. Mas não há ruptura definitiva. O tempo pesa sobre o homem, não sobre Deus. O afastamento prejudica o povo. Deus permanece.

Oseias 11 não é um capítulo sobre punição. É sobre amor que não desiste. Deus continua chamando. A eternidade dele não elimina o prejuízo do nosso tempo. Quem perde quando se afasta é o homem.

A pergunta não é se Deus permanece. A pergunta é se nós paramos de fugir enquanto ainda há tempo.