Isto é jeito de tratar seus objetos? -Domain Driven Design

quinta-feira, 11 de fevereiro de 2010

Engraçado como às vezes é mais fácil fazer o que é mais complicado do que o mais simples. Pelo menos esta é a única razão que eu encontro quando ouço alguém chamar "vidro" de "vrido". Deve ser mais fácil pronunciar "vrido", já que é mais complicado.

Posso não estar fazendo muito sentido pra vocês agora, mas já vão entender o que eu quero dizer.

Contemplem, por um minuto, esta modelagem "esquisitinha". Mais ou menos como um "r" fora do seu devido lugar:





Não é nada que interfira no funcionamento do sistema ou no entendimento de uma frase. Mas que diabos, estamos fazendo um sistema ou remendando uma colcha?
O que é aquele AlunoCurso ali no canto? E se você se depara com uma referência para DisciplinaSalaProfessorAluno depois de encontrar uma referência para DisciplinaSalaProfessor? Porque não tem um DisciplinaSala? ;-)

Um software é feito para resolver um problema de alguém. Este problema, em primeiro lugar, deve ser caracterizado. Parte desta caracterização envolve reconhecer as pessoas envolvidas e as entidades que executam suas ações em uma atividade problemática.

Quando se faz uma análise do problema, é importante analisar aquele problema e não perder tempo renomeando coisas que já existem, que já tem nomes. Muitas vezes as entidades envolvidas carecem de uma definição melhor delimitada ou de um consenso sobre sua responsabilidade e seu comportamento. Neste caso, um glossário ou até uma ontologia pode ajudar a resolver o problema. Pode ser que durante a análise até se descubra que é melhor retirar algumas responsabilidades de algumas entidades para criar uma nova, melhorando a coesão. No entanto, isto é uma questão totalmente de negócio, uma decisão sobre o domínio da aplicação, e quem entende do domínio é quem tem o problema e não quem pegou o bonde andando e ainda quer sentar na janela. ;-)

Vamos dar nomes existentes para aqueles caras do diagrama ali em cima e algumas coisas vão ficar mais claras:


Essa mania de substituir os nomes do domínio por nomes inventados em função dos relacionamentos das entidades, infelizmente, é muito comum. É péssima. Disruptiva. Uma pessoa nova que chega ao sistema demora a entender o que se passa no código. Uma mudança de requisitos, ainda que faça uso de uma matriz de rastreabilidade, apenas vai identificar quais classes serão alteradas. Qual alteração vai em cada uma é um custo. Tem-se que lembrar qual é a responsabilidade daquela classe em função de um nome artificial dado pelo relacionamento dela com as outras que não enfatiza o seu comportamento e a necessidade da sua existência. Não informa o problema que ela resolve. O que ela pode fazer.
Pior ainda, uma alteração que exija a inclusão de uma classe nova, criando novos relacionamentos, poderá fazer com que nomes deixem de fazer sentido.

Ah, para os que ainda estão com problemas de ver que os diagramas são equivalentes, aqui vai a mesma organização do primeiro no segundo:
OK, parece que eu trapaceei rearrumando o diagrama, mas eu explico. O processo que segui foi listar as classes com os nomes corretos (do segundo diagrama), criar os nomes esquisitos (do primeiro), construir o primeiro diagrama e depois construir o segundo.

A questão é que quando se faz as coisas mais complicadas do que se deveria, muitas vezes o nosso entendimento do problema fica prejudicado e a organização do diagrama acaba podendo refletir isso. Quais são as classes com mais relacionamentos, que parecem ser mais "centrais" no primeiro diagrama? Quais são as classes mais "periféricas", que tem cara de "atributos"? E no segundo? O que você acha que você colocaria no topo do diagrama, para facilitar o entendimento?

Quando se prejudica o entendimento do modelo de domínio, sobre o qual todo o seu software se baseará, se prejudica o entendimento de todo o software.

"O vrido, coloquei encima da táuba pra potreger da agua."
"Coloquei o vidro em cima da tábua para proteger da água."

Perceberam?

E aí, alguém quer comentar nomes "esquisitos"?

Abraço a todos!

Bookmark and Share

Um comentário:

Postar um comentário

 
addthis_config = { data_ga_tracker: pageTracker }