As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Práticas recomendadas
Promova a propriedade. Cada membro da equipe do projeto deve ter o poder de criar e possuir um ADR. Essa prática distribui o trabalho de pesquisa arquitetônico entre os membros da equipe e transfere esse trabalho do arquiteto de soluções ou do líder da equipe. Também promove um senso de propriedade no processo de tomada de decisão. Isso ajuda a equipe a adotar essas decisões mais rapidamente, em vez de tratá-las como decisões impostas por níveis mais altos da organização.
Preserve o histórico de ADR. ADRs deve ter um histórico de alterações e cada alteração deve ter um proprietário. Quando o proprietário do ADR atualiza o ADR, ele deve alterar o status do ADR antigo para Substituído, anotar suas alterações no histórico de alterações do novo ADR e manter o ADR antigo no log de decisões.
Agende reuniões regulares de revisão. Se você estiver em um novo projeto (greenfield), o processo de ADR poderá ser bastante intenso no início. Recomendamos que você estabeleça um ritmo regular de discussões e reuniões de revisão do ADR antes ou depois da reunião diária. Com essa abordagem, o definido se ADRs estabilizará em dois ou três sprints e você poderá construir uma base sólida com menos reuniões.
Armazene ADRs em um local central. Cada membro do projeto deve ter acesso à coleção de ADRs. Recomendamos que você os armazene ADRs em um local central e faça referência a eles na página principal da documentação do seu projeto. Existem duas opções populares para armazenar ADRs:
-
Um repositório Git, que facilita a criação de versões ADRs
-
Uma página wiki, que a torna ADRs acessível a todos os membros da equipe
Código de endereço não compatível. O processo de ADR não resolve o problema do código herdado não compatível. Se você tiver um código legado que não suporta o estabelecido ADRs, você pode atualizar gradualmente a base de código ou os artefatos desatualizados, ao mesmo tempo em que introduz novas alterações, ou sua equipe pode decidir refatorar o código explicitamente criando tarefas de débito técnico.