Neste post farei o
resumo do capítulo 2 do livro Domain
Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:
Existe uma grande diferença entre a mentalidade de
desenvolvedores e analistas de negocio. Os desenvolvedores costumam pensar e
imaginar o sistema na forma de classes, métodos, algoritmos, e tendem sempre a
fazer uma ligação entre os conceitos do mundo real com os conceitos de relações
e modelagens. Eles pensam em termos de herança, polimorfismo, Orientação a
Objetos, etc,... Já os especialistas no negocio não entendem nada a respeito de
bibliotecas, frameworks, persistências, e, em muitos casos, não conhecem até
mesmo banco de dados. Eles sabem somente a respeito das regras do negócio.
Um dos princípios fundamentais do DDD é usar uma linguagem
focada no modelo, e é sugerido que esta linguagem seja adotada em comum tanto
para documentação quanto para programação. Este princípio é essencial para
integração entre os especialistas de negocio e desenvolvedores.
Quando o time como um todo começa a usar essa linguagem
comum em todas as partes do projeto, tanto para se comunicar, como documentar e
desenvolver, acabam gerando uma linguagem conhecida no DDD como Ubiquitous
Language.
Essa linguagem em comum cria a premissa de que toda a equipe,
ao usar a mesma linguagem, irá descobrir ao longo dos meses, como o sistema
deverá funcionar e ajudará a descobrir inconsistências e conceitos inadequados
no design.
Para tanto, os especialistas no negócio deverão se opor a
termos técnicos ou difíceis de entender no modelo de negocio. Se no modelo
tiver algum termo que eles não consigam entender, então provavelmente algo está
errado. Assim como os desenvolvedores devem ficar atentos a inconsistências ou
ambiguidades no modelo.
Ao escrever o código usando a Ubiquitous Language para
criação de classes, métodos e atributos estará sendo feita uma ligação entre o
modelo e código. Esta prática vem a ser de extrema utilidade, visto que torna o
código muito mais legível, e auxiliará, posteriormente, nas alterações do
código conforme o crescimento do projeto.
Uma maneira eficaz para expressar classes, atributos e
relacionamentos é através da UML, entretanto, o comportamento entre as classes
não é tão facilmente expressado através desta documentação. Entretanto, pode-se
utilizar de notações no diagrama para tentar explicar o comportamento esperado
dos objetos. Esta documentação explicativa pode vir através de pequenos
diagramas de uma parte do modelo contendo a explicação necessária. Nestes
diagramas podem aparecer diversas classes e seus respectivos relacionamentos.
Esta documentação é de caráter temporário, podendo ser
feita, inclusive, a mão, significando pode ser mudada em um futuro próximo,
assim como o modelo pode ser alterado diversas vezes até ficar estável. De
acordo com as práticas da comunidade de Extreme Programming pode-se incluir
o código na documentação, pois um código bem escrito, utilizando as praticas de
TDD
(Test
Driven Development) e a Ubiquitous Language nas classes e
atributos pode deixar a codificação muito comunicativa.
Nenhum comentário:
Postar um comentário