DDD é de direita?

Nov 29 2022

“DDD é coisa de direita!” Por trás dessa declaração provocativa (ideal para lançar uma sessão unconf e ter pessoas), Simon Chaveneau queria se perguntar sobre o impacto do Domain Driven Design (DDD) em nossa organização (Product-Tech) para produzir software. Isso aconteceu durante nosso primeiro non-conference na Agicap, organizado para permitir que o pessoal do Produto e do Tech se encontrem para discutir, aprender, compartilhar, rir, mas acima de tudo ganhar altura em relação ao nosso dia a dia.

“DDD é coisa de direita!”

Por trás dessa declaração provocativa (ideal para lançar uma sessão unconf e ter pessoas), Simon Chaveneau queria se perguntar sobre o impacto do Domain Driven Design (DDD) em nossa organização (Product-Tech) para produzir software. Isso aconteceu durante nosso primeiro non-conference na Agicap, organizado para permitir que o pessoal do Produto e do Tech se encontrem para discutir, aprender, compartilhar, rir, mas acima de tudo ganhar altura em relação ao nosso dia a dia.

Nossa 1ª desconferência na Agicap, 13 de outubro de 2022

Durante uma desconferência, o programa é estabelecido pelo público. É feito durante uma sessão inicial de “Market Place” pela manhã. Durante esta primeira plenária do dia, cada um pode pegar stickies, um marcador e depois lançar suas sessões na frente de todos. Em seguida, as pessoas os posicionam no programa do dia (para mais informações sobre esta desconferência, existe este tópico no twitter )

Mas voltemos ao assunto e à intrigante sessão proposta por Simon.

Versão francesa de “DDD é coisa de direita!”

O reinado da propriedade privada?

Resumindo a proposta inicial de Simon: se seções inteiras de nosso SI pertencem a times — cada um responsável por um ou mais Bounded Context (BC) — não estamos diante de uma versão de software de propriedade privada (com arame farpado em volta dos BCs, etc.) .)? Daí seu provocativo “ DDD é coisa de direita! ”

E com a pergunta subsidiária: “Não seríamos mais eficientes com uma organização baseada em equipes de recursos? (com todos capazes de trabalhar em todos os BCs no caminho para seus casos de uso)”

Bem… devo admitir que esta sessão acabou sendo muito mais frutífera do que eu esperava inicialmente porque uma discussão realmente fascinante se seguiu sobre nosso modo de organização Produto/Tecnologia.

Mas ao invés de detalhar o caminho percorrido por esta sessão onde fomos muito numerosos (certamente interessante para descrever no contexto de outro post), vou descrever diretamente o que retive e pensei sobre o assunto.

Algumas observações

Um software eficaz é um software alinhado com os desafios do negócio . Por alinhado, queremos dizer um software que toma emprestado os termos certos do campo de domínio, que articula corretamente os conceitos-chave do negócio e convoca o mínimo possível a complexidade acidental trazida por questões técnicas. Esse é um dos principais desafios do Domain Driven Design (DDD), conforme explicado aqui em 3 minutos .
A Lei de Conway não é uma opção que alguém poderia escolher não tomar. ‍♂️ Ela age um pouco como certas leis físicas, como a atração da gravidade. Podemos tentar lutar contra isso ;-) mas ainda é válido na terra. A Lei de Conway é aquela lei de 1967 que afirma que
“Qualquer organização que projeta um sistema (definido amplamente) produzirá um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização”.
Em outras palavras, a arquitetura de um software é necessariamente o resultado dos modos de comunicação das pessoas envolvidas em seu projeto. Por exemplo, um compilador desenvolvido por 3 equipes provavelmente funcionará em 3 etapas ou terá 3 módulos distintos.
A Manobra Inversa de Conway (ICM) permite que você pense que alguém poderia controlar a lei de Conway. Inicialmente, essa manobra inversa foi sabiamente recomendada para “ quebrar os silos que restringem a capacidade da equipe de colaborar de forma eficaz”. Mas se transformou ao longo dos anos em uma recomendação boba: “ mude sua organização para atingir sua arquitetura de destino ”. Bobagem porque lembra: “A cultura come a estratégia no café da manhã”. Mais informações aqui nesse tópico interessante.
Domain Driven Design não impõe nenhuma organização. Dá chaves para possibilitar a sobrevivência, inclusive em casos de organizações disfuncionais (com times que estão em guerra ou se ignoram). O DDD nos ajuda a entender as questões de poder e as questões sociais entre as equipes. Como resultado, é antes uma ferramenta de libertação contra nossos determinismos ( daí uma ferramenta de esquerda, eu diria ;-)
Por outro lado, o DDD nos fornece ferramentas para poder projetar um software eficiente e o mais alinhado possível com relação ao domínio. Entre eles, o conceito de Bounded Context (BC), que nos propõe projetar modelos de usos, envolvê-los e protegê-los contra confusões/falsos amigos/mal-entendidos resultantes de outros contextos.
Para maior alinhamento e eficiência, DDD também recomenda enfaticamente que desafiemos regularmente nossa visão e nossa modelagem da solução. Também significa revolucionar e mudar os modelos de tempos em tempos seguindo um momento eureka (chamado Design Breakthrough ). É por isso que temos regularmente sessões de mapas de contexto aqui que refinam constantemente nossa visão do campo com o pessoal do produto.
As equipes de desenvolvimento têm equilíbrios frágeis. São necessários cerca de 6 meses de convivência e relacionamento interpessoal para que uma equipe de desenvolvimento seja realmente eficaz. Você adiciona ou remove uma única pessoa desta equipe e ela não é mais a mesma equipe (consulte Reagrupamento Dinâmico ). Em termos de eficiência, prefiro equipes que ficam juntas e mudam de assunto, do que equipes que são apenas explodidas/redistribuídas de acordo com os assuntos. Claro, se alguém está farto de sua equipe ou de seus assuntos, tudo deve ser feito para possibilitar que ele mude de equipe (estar bem pessoalmente é ainda mais importante para nossa eficiência coletiva)
Nossa organização atual e nossas equipes aqui na Agicap são bastante afiliadas a um ou mais Contextos Delimitados, a fim de levar em conta a complexidade do problema e capitalizar um mínimo de nossos respectivos conhecimentos de negócios. De vez em quando, algumas equipes podem ter um escopo muito grande e precisamos cortar e atribuir melhor nosso Contexto limitado. Por outro lado, essa divisão de BCs deve permanecer ligada aos conceitos de negócios (lembre-se do DDD)
Nada proíbe ter equipes de recursos em uma organização que faz DDD , desde que todos respeitem os limites dos Bounded Contexts.
Por enquanto, preferimos muito a prática de Swarming (uma espécie de task force constituída por pessoas de várias equipas mas onde a responsabilidade e a propriedade do artefacto final (ferramenta, api, biblioteca) é definida à partida. Ajuda para evitar a síndrome do “Bom, a gente faz uma coisa juntos, mas quem vai manter agora?!?”). Além de sua eficácia em conseguir que as pessoas certas colaborem dependendo do assunto, o swarming traz muito capital social para nossa organização ao promover temporariamente relacionamentos interpessoais entre equipes (super útil para o futuro quando todos voltarem para sua equipe).
Nossa atual organização de Produto está definida em 1 Gerente de Produto (PM) por equipe de desenvolvimento, mas talvez seja interessante ter PMs mais associados a assuntos de negócios do que a sua equipe?

Finalmente, eu diria que não há mais bala de prata na organização do que temos no desenvolvimento. Feedback, questionamento e experimentação contínuos são nossos companheiros neste caminho de melhoria contínua para efetivamente criar softwares relevantes para nossos usuários.