Ep. 217 - Explorando DDD e Team Topologies: desafios e oportunidades

Hoje a gente está aqui pra falar de dois assuntos que estão bem na moda dentro de engenharia e design: DDD e Team Topologies. O DDD já tem mais de 20 anos de história e é super mal compreendido. Vamos começar por ele. O DDD, até o próprio autor, Eric Evans, ultimamente vem fazendo palestras tentando explicar um pouco, porque durante esses 20 anos ele ficou muito conectado só com a parte de engenharia, e aí nasceu muita coisa em volta desse assunto. O Eric tem sido muito enfático em dizer que é muito mais sobre business do que sobre engenharia. É uma abordagem de design de aplicações muito voltada ao negócio, é como a gente conecta o que as pessoas de negócio estão falando com o que as pessoas de engenharia entendem sobre negócio. Essa conexão passa por várias abordagens, práticas e conceitos que o livro traz. Se você for parar pra ler hoje, depois de 20 anos, é uma linguagem muito complexa, você precisa ter um background de engenharia e uma experiência já relevante. No começo, parece uma piração, mas depois de alguns anos você fala: ah, era isso que o Eric queria dizer, agora tudo faz sentido. Um dos conceitos centrais é a linguagem ubíqua, que a gente traduz como onipresente: chegar ao ponto de definir e escrever seu código usando os próprios termos que o negócio usa. É muito comum em engenharia ver classes, métodos, funções escritos de uma forma e as pessoas de negócio falarem daqueles mesmos termos com outra nomenclatura, outra terminologia. O Eric é muito enfático em dizer que quanto menos a gente tiver esse atrito de linguagem, quando a gente vai falando a mesma coisa, mesmo vocabulário, quanto mais isso gera eficiência nas soluções e a gente se aproxima do problema que quer resolver de negócio. É um sonho antigo, mas atual: falar coisas que conversem entre os mundos e não criem abismos. No contexto de produto e design, se você está num contexto que não tem muita parte de experiência com o usuário, desenvolver esse tipo de conhecimento tem bastante valor. Várias pessoas de produto e de negócio não têm tanto contato com o desenvolvimento de software em si, nunca exerceram esse papel no dia a dia. Conseguir navegar num contexto onde as coisas são mais de back-end, não tem tanta tela, não tem tanta interface, compreender como o sistema está se comportando, como as regras vão ser aplicadas, facilita bastante. O que tenho tentado é usar bastante DDD nesse processo pra fazer um mapeamento de como o fluxo acontece, como o software vai se comportar, onde cada regra está se encaixando. Se você trabalha com front-end, com interface, aí você tem outras formas de fazer esse mapeamento, a aplicação já está mais fácil, tá ali na tela. No mercado financeiro, tem uma coisa que é camada: componente que chama o terceiro componente, que vai bater em algum barramento que precisa de compliance. Não falta espaço pra abordagem de contexto e coisas que não são simplinhas na tela. Não é só fazer um Pix, tem muitas camadas por dentro de um Pix. Na área de finanças de um banco, não tem nada a ver com o que o usuário está usando no aplicativo, tem muito pouco construção de tela. Sobre o DDD no dia a dia, existe o DDD voltado pra soluções de arquitetura no geral. Muita gente de engenharia usa o DDD pra estruturar melhor as aplicações, usa abordagens de agregação de domínios, bounded context, domínios compartilhados, modelos que transicionam entre áreas. Mas tenho ido muito mais pra um caminho do DDD estratégico. Como a composição dos times de software, de produto no geral, acaba sendo desenhada em torno das soluções de software, e aí, pegando a lei de Conway emprestada, por falta de uma boa modelagem de domínio. Ao fazer esse mapeamento de domínios, consigo cobrir potencial eficiência, agregar informações e diminuir o overhead dessas dependências entre áreas. Tem me ajudado a dar mais clareza sobre a estrutura organizacional atual, o raio-x, e como consigo desenhar um próximo passo de gerar eficiência pra dentro da empresa. No mínimo, a gente tá garantindo que todo mundo tá olhando pra mesma coisa. Os conceitos são esses, é isso, é nesse caminho? Vou dar um exemplo: cheguei na Cora, um mês aqui, e uma das coisas que a gente tava discutindo é que um time específico acabou assumindo vários projetos que outros times de produto não conseguiram pegar. Ele virou meio que um rio de domínio. Tem um monte de coisa que esse time cuida que, quando a gente começou a questionar, nos primeiros meses, a primeira coisa que me chamou atenção. Um determinado domínio tava nesse time e não no domínio que seria o principal dono. Na época, a gente acabou transferindo esse projeto que tinha data, era regulatório, então essa galera precisava fazer. Mas hoje, por que ainda continua aqui? Por que a gente tem tanta dependência daquele time e quem conhece mesmo o fluxo de negócio é aquele time, só que esse segundo ficou assumindo a responsabilidade de uma arquitetura que não tem profundidade de negócio. Nas conversas de priorização, a galera fala: vou implementar essa coisa aqui, mas tem que ver se no fluxo não tem alguma regra que vai gerar fricção pro usuário. Quem pode decidir ou ter mais visão de que isso gera ou não fricção é aquele time de origem, que sabe daquele domínio, que tá dentro daquele contexto. Já nesse primeiro momento, consigo usar a abordagem de DDD pra começar a dar mais contorno e responsabilidade pra cada time. O principal benefício que sinto é conseguir enxergar os domínios e tê-los melhor distribuídos pelos times. Se você está em alguma área, BU ou estrutura que tá crescendo bastante, isso ajuda muito. Outro benefício grande é da linguagem ubíqua. Tem várias palavras que a gente muitas das vezes nunca nem ouviu, a pessoa de negócio chama de um jeito, a de engenharia de outro, a de design de outro, a de dados de outro. No fim do dia, todo mundo fala da mesma coisa, mas dificilmente você consegue que todo mundo se entenda e use o mesmo termo. Uma coisa que frequentemente vejo desandando e que me preocupa é quando a gente vai fazer o mapeamento, quando vai começar a usar o DDD e o Event Storming pra conseguir fazer o mapeamento. As pessoas têm muita dificuldade de conseguir fazer o mapeamento e se preocupam em ter tudo, em ter todos os cenários possíveis. Quando vê, vai fazer um desenho gigantesco, um mapeamento enorme, demora várias horas, talvez até dias, e talvez isso não seja tão necessário. Você poderia fazer um mapeamento de 4 por 4, mas se não tiver alguém ali atento, o grupo não estiver preocupado com isso, eles vão ficar horas e horas pra fazer uma coisa que de repente nem tem tanto valor. É a treta constante da história. Se a gente estiver falando de DDD, pode trocar por Discovery, e o mesmo problema se aplica: fazer mais um Big Design Upfront, desenhar mais um pouquinho, a gente não pensou o suficiente. Pode levar uma hora, um dia, uma semana, um mês. É pra ser incremental, você não vai ter todas as coisas de uma vez. Existe uma ansiedade por adoção de padrões pra resolver problemas que talvez sejam conhecidos ou que a gente acha que são conhecidos. Vejo uma plataformização prematura acontecer em vários lugares. A pessoa fala: isso aqui é plataforma. Aí vai lá, cria um serviço com uma API e chama aquilo de plataforma. Não, esse aqui é um serviçinho que agora todo mundo pode usar, então esse é um time de plataforma. É parte daquela coisa de encaixar, bater martelo no parafuso. No DDD, na hora que você tá desenhando os eventos, usando uma ferramenta como o Event Storming, as pessoas esquecem que a ferramenta é pra mapear o raio-x da coisa, o que tá acontecendo agora. É justamente pra ter reflexões com aquele desenho, com aquela visão. A famosa regra do brainstorming: não apareceu ainda porque talvez ninguém tenha pensado nisso, então deixa quieto. Isso se aplica também com Team Topologies. Vi muita gente caindo no erro de sair desenhando a estrutura organizacional com os shapes que o Team Topologies sugere, como se isso fosse resolver alguma coisa de fato. Não é prática, você vai lá desenhar: isso aqui é um time enabling. Aí você vai ver que, na verdade, é só uma desculpa pra ter um time de operações, diminuindo a responsabilidade que era pra ser do time de produto. Tem várias disfunções que a galera apela, corre de cabeça nos padrões, sem fazer uma reflexão de como deve adotá-los. Uma frase que ouvi recentemente de um analista, um cliente nosso: Team Topologies é a famosa ferramenta que o meu gerente aprendeu pra poder fazer copia e cola e fazer uns desenhos bonitos pra dizer que ele sabe o que ele tá fazendo. E só pra dar um último disclaimer, nessa empresa tinham 80 plataformas criadas no intervalo de dois meses. Você não vai ter em dois meses 80 plataformas. Agora, qual o problema que o Team Topologies resolve? Se o DDD está criando uma linguagem comum, tentando fazer a gente olhar a realidade de uma linguagem de negócio, de estratégia de negócio, colocando engenharia pra falar a mesma língua, o Team Topologies é sobre o como fazer, como a gente vai fazer. O livro em si é bem denso, você vai encontrar várias ferramentas, vários métodos, vários frameworks lá dentro. No final é muito pra um direcional de como estão apresentando uma abordagem pra conseguir lidar com interações entre os times e como esses times poderiam ser. Uma coisa que muitas das vezes as pessoas exploram pouco: elas estão geralmente bem preocupadas em descobrir que tipo de time eu tenho, como se isso já fosse resolver. Mas o Team Topologies fala muito sobre como os times deveriam interagir também, possíveis interações que eles poderiam ter. São quatro formatos. No StreamAligned, você vai estar tendo uma interação mais direta com o fluxo, dá pra relacionar bem com a jornada do cliente. Tem um time enabling, que vai estar cruzando times que fazem esse fluxo de valor direto, habilitando coisas diversas. Existe o time de plataforma, que vai estar suportando outros times, vai ter interações com eles. E você tem um time de Complicated, que vai estar tendo domínios que não estariam diretamente no time alinhado ao fluxo, entregando valor pro cliente na ponta. Ele vai estar lidando com alguma coisa mais complexa que você precisa resolver no meio do caminho. E ele também interage com os outros times. Tendo essa estrutura, sabendo que existem esses tipos de time, você explora também as interações de como acontece entre eles. Na verdade, são os patterns de estrutura organizacional que eles trazem. O Matthew e o Manuel compilaram muita coisa que a gente já vinha falando nos últimos anos sobre estrutura de time. Tentaram compilar nos tipos de time, características que viram em comum, padrões e uma sugestão de como dar contorno e interagir entre eles. Tem muita coisa ali que conecta com o DDD, talvez por isso que a gente trouxe aqui: a questão da quantidade de domínios que um time deve ser responsável ou não e o quanto isso afeta a eficiência desses times em termos de carga cognitiva. Uma das causadoras de burnout, se você vai na ciência, é uma das causadoras de ter um pânico, uma crise. E quanto isso afeta o flow dos times, como a gente gera valor de forma mais eficiente sem ficar trocando tanto contexto. O caso que trouxe, esse time que assumiu uma bucha de outro time, que era domínio de lá, ao tempo que a gente ficou gastando numa conversa que esse time não tinha domínio sobre aquela decisão, não tinha profundidade de negócio pra entender se deveria estar ali naquele fluxo ou se ia gerar fricção pro usuário, enquanto que aquele time já tem. A carga cognitiva de conhecimento é muito menor, é um negócio simples pra eles: a gente já sabe que não funciona, a gente já experimentou, a gente já tem contexto. Tem uma heurística no livro: se você tiver domínio simples, idealmente cada time deveria lidar com um domínio. Mas tem um pouco do jogo da realidade versus o ideal. É bom porque dá um norte do que a gente precisa buscar, mas o problema é a interpretação que as pessoas levam ao pé da letra. Aí nasce o lance de monte de plataforma, times tão simplificados que a gestão de dependências começa a virar um problema, começa a aumentar o nível de coordenação de trabalho entre os times. Não adianta você ir lá dar shape pros times e a arquitetura de software ser totalmente oposta. Monolito travestido de microserviço, ou ao contrário, um monte de microserviço que, no fundo, se tivesse no monolito, seria muito melhor. O Team Topologies foi um dos grandes catalisadores pra trazer gestão pra dentro do mundo de engenharia, organização de time. Tava muito gol horse em várias estruturas de times e isso deu um pouco de cara de separar o joio do trigo. Tem coisa que é de fato plataforma, tem coisa que tá de frente com o cliente. O pior de tudo é: eu cuido da frente de loja, do app, do canal, da experiência, mas eu também cuido das 15 plataformas pra dentro. Essa é a carga cognitiva explodida. Porém, quero voltar numa treta: o quanto isso tá sendo aplicado de maneira evolutiva, consistente, consciente, pequenos passos, pequenos experimentos, resolvendo a dor por vez. O quanto a gente tá fazendo Big Design Upfront. A gente vai parar aqui dois meses e vai desenhar todos os cenários, pra você imaginar com a melhor estrutura de time do mundo e aí tá tudo resolvido. Como é que tá isso? Pergunta retórica. Existe uma linha tênue entre desenhar uma solução evolutiva versus contemplar todos os cenários. O que eu vejo é que a gente sempre pende pra contemplar todos os cenários e não se prepara pro futuro. Quando a gente tá construindo os domínios e fazendo o Event Storming, percebe que algumas coisas, se a gente não desenhar a arquitetura pensando no futuro, vai criar um autoacoplamento do negócio com aquele software. Isso pra mim não é sobre Big Design Upfront, mas é sobre entender que aquilo pode evoluir pra um próximo passo sem desenhar todos os cenários. A confusão acontece porque a galera, quando fala de ser evolutiva, não pensa nesse aspecto, pensa realmente em cobrir todos os corner cases, o single point of failure. Na hora que eu tô desenhando uma arquitetura, eu preciso desenhar meus módulos à prova de uma extração. Isso um dia pode sair daqui, não posso criar uma dependência e acoplar esse software dentro do que eu tô construindo. Só que isso requer experiência, vivência com o software. Se você vem com uma abordagem de Event Storming num grupo que não tem vivência suficiente pra ter essa maturidade de não ir pro caminho do Big Design Upfront, mas pensar no evolutivo, isso é uma bomba relógio. Você cria um monte de microserviços só por ego: olha que legal os nossos serviços, a gente cuida de 59 serviços, e aí você vai ver um monte de funçãozinha espalhada que deveria estar dentro de um módulo unificado, num domínio. Existe esse desejo de Big Design Upfront que precisa ser separado do que é evolutivo. Dica de quem tá usando no dia a dia: cuidado, use com moderação, faz 80-20, busca um meio do caminho. Carga cognitiva no dia a dia é bem complexo, talvez em todos os lugares, em finanças não vai ser diferente. A gente tem muitos domínios e, como não tem muita parte da interface, a interação com o usuário, a maioria das pessoas sabe como é o comportamento do saldo, de uma fatura, mas saber como é o comportamento de uma PCLD já é diferente. Quem classifica os domínios pra pensar na carga que o time tá tendo, geralmente é o próprio time. Boa parte das pessoas daquele time acha super complexo aquilo porque não conhece, são pessoas que não trabalharam com aqueles domínios. Pra conseguir reduzir, você precisa investir em ter um time multidisciplinar, pessoas que conhecem bastante sobre aquilo, pra conseguir colaborar e passar conhecimento, reduzindo a complexidade do domínio e a carga cognitiva. Na maioria das financeiras, elas acabam terceirizando muito o sistema como um todo. A sua carga vai aumentando à medida que você vai internalizando aquilo. Vários bancos passam por esse momento. O que tenho tentado fazer é como a gente não explode a carga cognitiva de um time. No geral, os times acabam tendo uma carga cognitiva mais elevada do que o que tá no livro, que talvez seja o cenário dos sonhos. É mais sobre o direcional, a gente gostaria que fosse daquela forma, o próximo daquilo, mas a gente tá distante. Aí entra o trabalho de produto: a gente não tem como priorizar tudo, se tudo for prioridade, nada será. Precisa decidir que domínio a gente vai atacar primeiro pra conseguir reduzir essa carga e não sobrecarregar todo mundo. Carga cognitiva como time está diretamente ligada às pessoas, à pessoa passar por burnout. Carga cognitiva igual redução de lead time ou aumento de lead time. Se você se afastou alguém, o time perdeu capacidade, vai ficar mais lento, mais dependente. Os custos de ter uma carga cognitiva alta: o lead time entra nisso, o quanto essa troca de contexto entre domínios muito diferentes gera no time. Primeiro, você perde profundidade, as pessoas têm conhecimento raso, o software começa a não atender, a gente começa a falar coisas diferentes. O acúmulo de assuntos gera possibilidade de aumento de incidentes, reduz o mean time to recover, o tempo que demora pra voltar as aplicações funcionando, porque se você não tem domínio suficiente de profundidade, vai demorar pra descobrir o problema. Quando a gente tá falando dessas métricas, a gente tá falando da chave pra destravar, pra fazer o unlock de boa parte dessas priorizações. Vai ter muita coisa pra fazer, é só mais um dia normal no mundo da engenharia, de produtos. Mas métricas são a chave, colar essas métricas no que tá doendo pro seu negócio, pra estratégia de negócio, é o carro-chave pra conseguir discutir aquilo que você não vai fazer. Geralmente você fica tentando confrontar métricas de times, pra tentar entender se um time tá ficando mais rápido, o outro mais devagar, e acaba caindo nessa furada. O mapeamento, usando DDD e Team Topologies, você consegue entender que tem times que têm domínios mais complexos e que a carga tá bem sobrecarregada. Você consegue ver isso pelo throughput, talvez o time tenha uma taxa de entregas bem menor do que outro que tá com domínios mais simples. Quanto a prioridade, o Banco Central diz a data que tem que ser entregue e acabou. Tem uma relação de como priorizar coisas que o Banco Central já disse que tem que ficar pronto até tal dia. Por conta desse tipo de cenário, você não consegue ter flexibilidade muito grande, tá trabalhando só com data fixa. Pra conseguir priorizar, tá muito ligado a ter boas estruturas de time, acompanhar as métricas pra saber se faz sentido aquelas datas, se você vai conseguir atender usando o histórico que o time tem. Ao invés de pedir pras pessoas fazerem tudo buscando evitar o atraso, fatalmente você acaba atrasando. Outro caminho é como você consegue fazer vínculos financeiros com aquilo. Às vezes uma coisa tem data fixa, ainda assim, se você atrasar a multa, talvez seja menor do que outra. Tentar encontrar outros indicadores pra ajudar na priorização. Vale muito a pena tentar se aproximar mais das áreas de negócio que às vezes a gente não comumente se afasta. A galera de riscos, às vezes, é muito conhecida por ser muito conservadora, mas tenho tido muitas interações com o pessoal e tem sido muito legal ver o quanto eles têm profundidade de coisas de negócio que a gente fica discutindo em software e produto achando que tá descobrindo o mundo. Existe o plano de continuidade de negócio, que todo mundo já deve ter ouvido falar. Uma das coisas é levantar todos os processos que a empresa tem. Se você pega os frameworks que a galera usa, que são super antigos, lá tem coisas que a gente hoje tá chamando de domínios. Tem um processo lá que é fazer tal coisa, a gente falou: a gente tá mapeando domínio e dando o mesmo nome, tá feito já. Será que a gente não tem oportunidade de utilizar esse esforço, que tá muito distante de engenharia, e se aproximar dessa galera pra construir alguma coisa em conjunto? Tem um exemplo no Ubank, que o Brunão fez com o pessoal de riscos e compliance, um software que ia cuidar de lavagem de dinheiro, integrar com um parceiro. O quanto usar o Domain Storytelling, outra prática de DDD, junto com a galera de risco, quanto foi rico, porque as pessoas entendem do negócio de risco, de fraude, muito mais do que talvez uma pessoa desenvolvedora que entende de engenharia. Aproximar esses mundos é a dica que dou pra toda pessoa gestora: tenta tirar um pouco seus vieses e preconceito de que a galera é muito conservadora. Traz pra conversa, traz usando essas formas de colaboração na hora de desenhar software, que você vai se surpreender. A outra dica é apostar em experimentar estruturas de times um pouco mais que fujam da ortodoxia. A gente veio de um histórico de modelos Spotify, squad, tributo, mas talvez a gente tenha modelos de organização que a gente consiga testar e experimentar, que consiga usar melhor a eficiência das pessoas, dos domínios e do conhecimento. Tente analisar melhor, será que essa estrutura que eu tô desenhando, mesmo que usando Event Storming, DDD, Team Topologies, realmente tá sendo eficiente, ou se no fundo é só pra ter mais um projeto pra botar no currículo, postar na LinkedIn Disney a foto bonita dos times organizados e não dar resultado nenhum. No fim, é muito sobre a provocação das métricas, aonde mora o resultado, aonde o calo tá apertando. Está num cenário de juros altos, não é uma opção buscar investidor, essa fonte secou e tem que dar resultado, no mínimo tem que empatar. Acabou essa história de ter um squad pra cada coisa nova e tá tudo bem, bota mais time, bota mais gente. Esse cenário trouxe um pouquinho de racionalidade ao mesmo tempo e explodiu o contexto na cabeça de muita gente. Cuidado, porque nesse momento de cortar custo, muitas vezes a gente tá falando de corte de pessoas e aí tem umas mexidas em time, sai do 8 pro 80. Muito cuidado com a carga cognitiva, com só um desenho bonitinho porque vai parecer mais barato. Tem muito streamline nascendo, bota os componentes lá dentro, tá tudo bem, vai resolver, tá só travestindo com framework novo, práticas antigas. E reorgs, no geral, fazer esses desenhos e construir ideias pra gerar mais eficiência pode gerar o pressuposto de que você vai ter que fazer grandes reorganizações. Toda hora a gente tá mudando o time. O DDD tem a vantagem de discutir coisas que são mais perenes, que vão durar mais do que alguns ciclos. Quantas vezes eu já passei por isso: contrata 30 pessoas pra um time numa aposta, estrutura, cria um monte de papel de gestão, e oito meses depois, nove meses depois o time é desfeito, porque não conseguiu sair nada pro mercado. São os domínios emergentes, que a gente fala no DDD, que tá nascendo ainda, a gente não precisa ter o contorno exato, a gente nem se provou. O que eu vou apostar todas as minhas fichas num negócio super incerto? É um cuidado que a gente tem que ter, como um tipo de empréstimo novo, com garantias. E aí tem toda uma série de coisas que pode dar errado mesmo, porque é um experimento, faz parte.