Artigos .NET Aplicando DDD e TDD em conjunto
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Conteúdo sobre boas práticas.
Aplicando DDD e TDD em conjunto
Como criar uma arquitetura modular, robusta, adaptável a qualquer ambiente e ainda garantir que a mesma esteja totalmente aderente às regras de negócio? Neste artigo será apresentado um pouco sobre as boas práticas do DDD (Domain Driven Design) mutuamente com a técnica TDD (Test Driven Development). Sobre estes serão exibidas as principais fases do desenvolvimento. Para isto será mostrado o funcionamento do ciclo do TDD, conceitos e codificação sobre: Entidades, Objetos de valor, Regras de domínio, Repositórios, Módulos, Mock, ObjectFactory e Facade.

Em que situação o tema é útil
Atualmente todo ambiente corporativo sofre constantes mudanças e seu setor tecnológico deve acompanhá-lo. Tantas mudanças tendem a gerar várias falhas, códigos replicados e regras de negócio espalhadas. Para resolver este cenário problemático sem gerar e espalhar novos erros existe uma combinação muito eficiente, DDD e TDD, um centraliza todas as regras do negócio e outro garante que mesmo após todas as adequações, inclusões ou alterações, tudo continue funcionando.

Atualmente o desenvolvimento de software é carregado por uma série de siglas sendo que estas normalmente significam alguma metodologia de desenvolvimento, prática ou simplesmente conceitos que se aplicados corretamente podem trazer benefícios para o seu projeto.

Neste artigo falaremos de duas destas siglas mágicas que estão sendo cada vez mais discutidas e praticadas no mercado: o TDD e o DDD. Ao longo do artigo veremos os principais conceitos sobre estas duas boas práticas de desenvolvimento, além de exemplos práticos para facilitar sua compreensão do assunto.

Com a grande mutação de regras de negócio que existe atualmente no meio corporativo, o setor tecnológico deve ter fôlego para acompanhá-las. Para podermos garantir que tudo funcione e que não se gere mais esforço do que o necessário, nada é mais eficiente do que se iniciar qualquer projeto pelos seus testes, e é exatamente isto que prega a técnica de desenvolvimento TDD.

TDD, que significa Test Driven Development, ou em português Desenvolvimento Dirigido por Testes, é uma técnica baseada em um ciclo composto por cinco passos na seguinte ordem:

1. Criar um teste que represente uma regra de negócio;

2. Executar o teste (obviamente ele irá falhar, pois ainda não existirá implementação da regra de negócio);

3. Escrever o seu código até o teste funcionar;

4. Refatorar o seu código desenvolvido;

5. Executar o teste novamente.

O princípio básico do TDD é primeiro o teste e depois a construção, desta forma esta técnica garante que sua aplicação só tenha código suficiente para suprir o negócio, e nada mais. Se você diz que usa TDD, mas não começa o seu desenvolvimento pelo teste, você está fazendo isso errado.

Como não poderia ser diferente, o primeiro projeto da solução é o de testes. Ainda vazio, começaremos nosso projeto pela entidade Pessoa (futuramente falaremos mais sobre entidades). Vamos criar uma regra fictícia, onde todas as pessoas para serem consideradas válidas devem ter pelo menos nome e CPF, sendo assim, já conseguimos definir o nosso primeiro teste: Dado_Uma_Pessoa. Quando_Crio_Deve_Ser_Valida(), conforme visto na Listagem 1.

Listagem 1. Código teste pessoa valida


  01 [TestMethod]
  02 public void Quando_Crio_Deve_Ser_Valida()
  03 {
  04     //arrange:
  05     string cpf = "12345678909";
  06     string nome = "Pessoa da Silva";
  07
  08     //act:
  09     Pessoa pessoa = new Pessoa(cpf, nome);
  10
  11     //assert:
  12     Assert.IsNotNull(pessoa);
  13     Assert.IsTrue(pessoa.Cpf == cpf);
  14     Assert.IsTrue(pessoa.Nome == nome);
  15 }

Como já era esperado, o primeiro erro é o de compilação, pois a classe Pessoa ainda não existe (nem o seu projeto existe ainda). Segundo foi definido acima, para uma Pessoa poder existir no nosso negócio, é necessário no mínimo que ela contenha nome e CPF, então obrigatoriamente estes dados devem ser cobrados no construtor da classe, e a mesma não deve permitir ser instanciada sem estas características, assim conseguimos garantir que a nossa classe adere ao negócio em qualquer situação. Sendo assim, conseguimos encontrar dois novos testes: Dado_Uma_Pessoa. Nao_Devo_Conseguir_Criar_Sem_Cpf e Dado_Uma_Pessoa. Nao_Devo_Conseguir_Criar_Sem_Nome, onde o esperado vai ser uma exceção impedindo a ação que contradiz ao negócio, como podemos ver na Listagem 2.

Listagem 2. Teste da regra de negócio da Entidade Pessoa


  01 [TestMethod]
  02 [ExpectedException(typeof(NetMagazine.Dominio.Excecao.ExcecaoParametroInvalido))]
  03 public void Nao_Devo_Conseguir_Criar_Sem_Cpf()
  04 {
  05     //arrange:
  06     var cpf = null;
  07     string nome = "Pessoa da Silva";
  08
  09     //act:
  10     Pessoa pessoa = new Pessoa(cpf, nome);
  11
  12     //assert:
  13     //O esperado para este teste é uma exceção não deixando eu instanciar
  14     //a classe Pessoa.
  15 }

Através deste teste conseguimos garantir que nunca existirá uma entidade Pessoa não válida instanciada em todo o nosso ambiente sistêmico, que por sua vez estará totalmente alinhado com o negócio para o qual nossa aplicação foi desenvolvida.

Por fim, implementaremos nossa tão falada e esperada classe Pessoa, e esta deve fazer todos os testes passarem corretamente, como podemos ver na Listagem 3.

Listagem 3. Entidade Pessoa


  01 namespace NetMagazine.Dominio.Comum.Entidade
  02 {
  03     public class Pessoa : Entidade
  04     {
  05           public Pessoa(string cpf, string nome)
  06           {
  07                  if (string.IsNullOrWhiteSpace(cpf))
  08                         throw new Excecao.ExcecaoParametroInvalido("Pessoa.Cpf");
  09
  10                  if (string.IsNullOrWhiteSpace(nome))
  11                         throw new Excecao.ExcecaoParametroInvalido("Pessoa.Nome");
  12
  13                  this.Cpf = cpf;
  14                  this.Nome = nome;
  15           }
  16           public string Cpf { get; protected set; }
  17            public string Nome { get; set; }
  18     }
  19 }

Em um modelo mais complexo, todos os testes não irão passar logo de cara, mas antes de refatorar qualquer código, tenha em mente deixar todos os testes funcionando e sempre os mantenha assim.

Entidades e regras de domínio

DDD significa Domain Driven Design ou Design Dirigido ao Domínio, e ao aplicarmos este modelo veremos que nosso foco será todo voltado ao domínio, onde estarão todas as nossas regras de negócio. Para gerenciar essas regras o domínio conta com Entidades, Objetos de valor, Repositórios abstratos e Serviços de domínio. Vamos a primeira e mais básica composição do domínio, a Entidade.

...

Quer ler esse conteúdo completo? Tenha acesso completo