Engenharia de Produtos e Sistemas
Transformar operações complexas em software.
Produtos com múltiplos domínios, jornadas, regras e exceções têm a maior parte do seu custo decidida antes de alguém escrever código.
Quando o produto cresce mais rápido que o entendimento dele.
A regra vive em três lugares
Uma parte no código, uma no banco e uma na cabeça de quem está há mais tempo.
Ninguém sabe em que estado o pedido está
Os estados nasceram um a um, e hoje existem combinações que não deveriam existir.
Toda mudança pequena leva um trimestre
Não pela mudança, mas pelo teste de tudo que ela pode ter quebrado.
Time novo demora meses para produzir
Sem o domínio modelado em lugar nenhum, entrar no produto vira arqueologia.
O que essa frente decide.
Modelagem de domínio
Nomear o que existe no negócio antes de decidir como vira tabela. Quando o modelo espelha a operação, produto e engenharia discutem nas mesmas palavras.
Arquitetura de produto
Onde ficam as fronteiras: o que muda sozinho e o que muda junto. É o que define quantos times conseguem trabalhar em paralelo dois anos depois.
Regras de negócio
Tirar a regra de dentro do código e colocá-la onde quem responde por ela consegue ler e mudar. Regra escondida em condicional só existe enquanto quem escreveu ficar.
Desenho de fluxos
Estados, transições e o que acontece quando o caminho feliz não acontece. A maior parte do custo está nas exceções, e elas são desenhadas depois ou não são.
O produto volta a caber na cabeça de quem o opera.
Mudança que cabe em um módulo
Fronteiras explícitas fazem a alteração parar de percorrer o sistema inteiro.
Regra legível por quem responde por ela
A área de negócio verifica o que o sistema faz sem pedir relatório.
Exceção prevista, não descoberta em produção
Os caminhos infelizes desenhados junto com o feliz, que é quando custam barato.
Em produção nos clientes
Errar no começo é o que sai mais caro.
Conte o que você precisa construir e mostramos por onde começar.