Modelagem tática: humanizando seu domínio – Resumo

Olá, tudo bem? No dia 17/11/2016 aconteceu a terceira live da software em contexto. Neste cast falamos sobre modelagem tática e dois dos principais artefatos que compõem o modelo de domínio: Entidades e objetos de valor (VO).

Como de costume, vou sintetizar o que foi discutido no cast, com o objetivo de ajudar a consolidar o conteúdo. Espero que gostem 🙂

Modelagem tática

Podemos dizer que a Modelagem tática(ou padrões táticos) são os tijolos que utilizamos para construir um modelo de domínio, garantindo que ele tenha seu comportamento claro e que capture e transmita significado. Ou seja, que seu software seja expressivo.

Entidades

Todos nós passamos por várias mudanças ao longo da nossa vida. Em um certo momento, podemos estar com os cabelos compridos ou curtos, com barba ou sem barba, e cada vez mais diferentes.

Mesmo com tanta mudança, o nosso RG permanece o mesmo pelo resto da nossa vida, apesar de alguns de nossos atributos mudarem, essas sequencias numéricas são únicas.

Essa é a essência de entidade. As entidades são artefatos que se distinguem por serem únicos, isto é, por possuírem uma identidade.

Identificando e definindo uma entidade

Até agora, conseguimos entender o que é uma entidade, entretanto, identificarmos e definirmos uma entidade na construção e entendimento de um software não é tão fácil.

Normalmente, quando estamos conversando com os experts de negocio, um alerta de que existe uma entidade é quando se fala bastante em buscar/encontrar e mudar.

Em um sistema hoteleiro, para realizar uma reserva, o funcionário do hotel solicita algumas informações do cliente. Ao chegar no hotel, para fazer o check-in, o cliente informa seu nome e o funcionário busca o cliente em sua lista de reservas. O funcionário encontra duas reservas para o nome fornecido, entretanto, para confirmar, o funcionário pergunta qual o CPF do cliente. Com o CPF informado, o funcionário encontra o cliente correto e muda seu status para hospedado

Com base no exemplo acima, podemos tirar as seguintes conclusões:

1ª – O nome e CPF são utilizados para  encontrar o cliente. Essas duas informações são essenciais para o cliente, pois são utilizadas para encontra-lo. Além disso, conforme falamos, buscas são indícios de que temos uma entidade em mãos.

2ª – O cliente ao realizar o check-in, tem seu status definido como hospedado. Aqui identificamos que o usuário pode ter seu estado alterado, isto é, o cliente é mutável. Outro indicio que o cliente é uma entidade.

3ª – CPF é um identificador do cliente. Levando em conta que o funcionário utiliza o CPF para confirmar qual o cliente correto, não podemos ter dois clientes com o mesmo CPF. Sendo assim, temos aqui uma identificação única para cada cliente.

com as informações coletadas até agora, podemos ter a seguinte entidade cliente:


public class Cliente
{

     public string Cpf {get; private set;}

     public string Nome {get; private set;}

     public Cliente(string cpf, string nome)
     {
        Cpf = cpf;
        Nome = nome;
     }

}

Você pode estar pensando agora: “Mas e o endereço do cliente, idade entre outras informações?”. Veja, isto foi proposital, pois este é um cenário confortável para maioria de nós que já trabalhamos com inúmeros clientes e sabemos o que um cliente tem. Entretanto, em um cenário aonde o domínio é desconhecido por você, defina suas entidades por suas características intrínsecas. As demais informações vão surgindo conforme o seu entendimento vai crescendo.

A ideia aqui não é mostrar exatamente como um sistema hoteleiro funciona, mas sim como podemos utilizar as informações fornecidas pelo expert de negocio para identificar e definir nossas entidades.

Objetos de Valor (VO)

Objetos de valor é um artefato bem poderoso que o DDD nos fornece. Eles são fáceis de testar, criar, usar, otimizar e manter.

Objetos de valor são definidos por serem o oposto de uma entidade. Eles não possuem uma identidade, são definidos pelos valores de seus atributos.

O “Telefone” de um hospede poderia ser definido como um VO, pois um telefone não é só uma sequencia de 8 dígitos. Precisamos saber se é um celular ou um residencial, qual o código de DDD (discagem direta a distância) , entre outras validações dependendo do seu negócio.

Veja que, um objeto de valor não é simplesmente um aglomerado de atributos, eles possuem um conceito que é definido pela Linguagem onipresente (UL) do seu domínio. VO’s trazem expressividade.

Uma outra características dos objetos de valor é que eles são imutáveis, isto é, seus valores não são alterados. Caso o seu telefone celular mude, você não altera o valor do seu objeto, você cria um novo objeto “Telefone”.

Os métodos de um objeto de valor são side-effect-free, isto é, os métodos não alteram o estado do objeto, eles são Query methodos.

Conclusão

Pessoal, espero que este post tenha ajudado a esclarecer algumas duvidas que possam ter surgido. Ha muita coisa que podemos dizer sobre entidades e objetos de valor, quem sabe eu escreva um outro post explanando com mais detalhes cada um desses artefatos 🙂

Espero que tenham gostado! Não deixe de dar seu feedback, ele é bem importate! Qualquer duvida ou critica fique a vontade para deixar nos comentários.

Para quem não viu, abaixo o cast que foi gravado e que está no canal da software em contexto:

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s