Leia os comentários recentes do tio Bob sobre o papel do design no TDD .
O design orientado a domínio envolve muitos padrões técnicos, definindo camadas bem estabelecidas, como Camada de aplicativos, Camada de infraestrutura, Camada de domínio, Camada de persistência.
Udi Dahan: "Deus, como eu odeio camadas." Ele passa algum tempo discutindo isso em sua palestra CQRS - mas Diferente (as camadas começam às 18h30)
Eu escreveria sua sentença um pouco diferente; "O DDD reconhece que há uma série de preocupações comuns à maioria dos aplicativos de negócios e que as soluções para essas preocupações têm vida útil diferente" .
Por exemplo, as preocupações com o domínio, em regra, precisam ser flexíveis - especialmente quando você está personalizando uma solução para um negócio específico. Afinal, o domínio diz respeito à forma como a empresa faz negócios, ou seja, como a empresa ganha dinheiro e ser capaz de oferecer melhorias nos negócios rapidamente é uma receita gratuita.
Por outro lado, você provavelmente não precisa alterar o componente de persistência com frequência. A solução de banco de dados que funcionou na última versão provavelmente também funcionará nesta versão.
As preocupações de aplicação estão em algum lugar no meio; eles tendem a ser estáveis para que os usuários não precisem aprender um novo aplicativo a cada lançamento.
Além disso, pode haver várias implementações para resolver qualquer preocupação. Por exemplo, o aplicativo pode precisar apenas de um instantâneo de seu estado atual - basta salvar um arquivo no disco. E nas suas primeiras iterações, também pode ser tudo o que o domínio precisa. Mas, finalmente, chega uma história que exige suporte a consultas ad-hoc, e você reconhece que configurar um banco de dados relacional será muito mais fácil do que implementá-lo do zero. E há esse recurso que funcionaria melhor em um banco de dados de gráficos.
Enquanto isso, o CTO quer uma versão do aplicativo que seja executada em seu telefone; o CEO acabou de ouvir de um cara que publicar uma API é algo importante.
Além disso, a equipe de vendas usa um modelo diferente, portanto, forneça o mesmo aplicativo, com um modelo diferente. Ah, mas estamos viajando muito, por isso nossa versão precisa funcionar quando estiver offline e sincronizar mais tarde ...
Em outras palavras, você aplica os padrões táticos do ddd não implementando espaços reservados vazios e assumindo que eles serão preenchidos posteriormente, mas reconhecendo quando você está cruzando os fluxos "Ei, esse é o código de persistência no meu modelo de domínio, não devo ser refatoração ainda. "
