Refatoração em design orientado a domínio [fechado]

Acabei de começar a trabalhar em um projeto e estamos usando o design orientado a domínio (conforme definido por Eric Evans em Design orientado a domínio: lidando com a complexidade no coração do software . Acredito que nosso projeto seja certamente um candidato a esse design como Evans descreve em seu livro.

Estou lutando com a idéia de refatorar constantemente.

Eu sei que a refatoração é uma necessidade em qualquer projeto e acontecerá inevitavelmente à medida que o software for alterado. No entanto, na minha experiência, a refatoração ocorre quando as necessidades da equipe de desenvolvimento mudam, não como a compreensão do domínio muda ("refatorando para uma maior compreensão", como Evans chama). Estou mais preocupado com avanços na compreensão do modelo de domínio. Entendo fazer pequenas alterações, mas e se for necessária uma grande alteração no modelo?

Qual é uma maneira eficaz de convencer a si mesmo (e a outros) que você deve refatorar depois de obter um modelo de domínio mais claro? Afinal, a refatoração para melhorar a organização ou o desempenho do código pode ser completamente separada da expressividade em termos do código de linguagem onipresente. Às vezes, parece que não há tempo suficiente para refatorar.

Felizmente, o SCRUM se presta à refatoração. A natureza iterativa do SCRUM facilita a construção de um pequeno pedaço e a alteração dele. Mas, com o tempo, essa peça ficará maior e se você tiver um avanço após essa peça ser tão grande que será muito difícil mudar?

Alguém já trabalhou em um projeto usando design orientado a domínio? Se assim for, seria ótimo obter algumas dicas sobre este. Gostaria especialmente de ouvir algumas histórias de sucesso, já que o DDD parece muito difícil de acertar.

Obrigado!

Sou um grande fã de DDD há um tempo (com e sem a rede de segurança de uma estrutura de teste).

Todo o conceito e o ciclo de vida da refatoração não mudam porque agora você está usando uma nova metodologia de design. Se levar um tempo significativo, é necessário que haja um benefício proporcional ao projeto para obter esse tempo da gerência.

Com relação a fazê-lo: em um exemplo, participei de uma refatoração importante de três meses por causa de um 'avanço' no entendimento do modelo de domínio. Exigia testes para verificar o comportamento atual, testes para verificar o comportamento esperado e alterações no código de chamada. Os benefícios foram significativos, no entanto, e permitiram que a empresa fizesse muito mais coisas que precisava fazer antes, mas simplesmente não conseguiu. Em essência, a refatoração era essencialmente uma 'característica'.

Refatoração no Design Orientado a Domínio é, penso eu, dirigida a uma necessidade, não a um refator "bom". Assim que você identifica um modelo de domínio incorreto, o código / sistema não está representando o problema do mundo real.

Caso em questão, recentemente trabalhamos em um aplicativo com razoável complexidade de domínio. Era um sistema de cobrança / contrato e estávamos introduzindo um novo tipo de taxa. Estávamos usando um processo ágil, scrums de 2 semanas para ser mais preciso.

Inicialmente, identificamos no modelo que as duas taxas eram completamente separadas e não tinham relação, exceto através do Contrato. No entanto, à medida que completamos mais histórias, chegamos à conclusão de que elas realmente eram as mesmas, especialmente quando começamos a agrupar a nova taxa como antiga apenas para fazê-la funcionar. Este foi o primeiro sinal de alerta.

Para encurtar a história, fomos capazes de obter 90% das histórias feitas com o modelo incorreto, mas chegamos ao ponto em que em todas as partes do código estávamos quebrando a nova taxa como antiga e / ou criando se newRate else oldRate TODOS os locais. Estávamos batendo a cabeça contra a parede de tijolos proverbial. Estávamos no meio dessa parte do projeto e sabíamos que o tempo para concluir seria exponencial ou impraticável com o modelo de domínio incorreto. Então, mordemos a bala, dividimos uma história em outras oito e refatoramos o Modelo de Domínio.

Quando concluímos o projeto, sabíamos, retrospectivamente, que era a coisa certa a fazer e a ÚNICA coisa a fazer para acertar.

Levou tempo? Sim, mas se não o fizéssemos, levaria mais tempo. DDD foi feito corretamente? Bem, curiosamente, não sabíamos sobre DDD na época, mas logo depois de assistirmos a um workshop de Eric Evans por DDD, tudo o que eu e meus colegas pudemos fazer foi concordar. Acho que se soubéssemos DDD, teríamos escolhido o refator muito mais cedo, economizando mais tempo.

Se você errar algo no Modelo de Domínio, é importante corrigi-lo. Na minha experiência, perdemos um pouco de como o modelo de domínio se conecta a suas diferentes entidades quando implementamos parte dele.

O que resultou foi que as pessoas costumavam modelar de maneiras que não eram pretendidas e, portanto, quebram outras partes do modelo para tentar "fazê-lo funcionar".

Assim que você perceber que há algo errado no modelo de domínio, altere-o o mais rápido possível. Quanto mais tempo levar para você refatorá-lo, mais difícil será mudar em relação aos usuários, cujos modelos mentais agora estão adaptados.

Para algumas partes do código, a refatoração contínua é um exagero. Para alguma outra parte do código (no DDD, o chamado Domínio Principal ) é uma necessidade. A compreensão de que o código não é como deveria colocar uma carga cognitiva extra no desenvolvedor (a diferença entre nossa compreensão do domínio e a implementação atual) que tornará as evoluções mais difíceis e / ou caras.

A questão é: "essas evoluções serão necessárias?". No domínio principal (a área que está fazendo a diferença nos negócios), a resposta é "Sim!". Porque essa é a poção do domínio em que a empresa está mais preocupada e aquela que fará a diferença para as partes interessadas. É nesse local que você deseja manter seu código em perfeito estado, pronto para implementar o próximo requisito com o mínimo de esforço, devido à flexibilidade do seu Modelo de Domínio.

No entanto, isso será caro quando aplicado a todo o código do aplicativo. Áreas que não são tão significativas para os negócios ( subdomínios de suporte ou genéricos na linguagem DDD) podem exigir uma abordagem menos sofisticada do que a reservada para o núcleo.