Domain Driven Designer
“Software design is an art, and like any art it cannot be taught and learned as a precise science, by means of theorems and formulas.”
Domain-Driven Designer
Apesar de ser um tema frequente no meio dos desenvolvedores mais experientes, o Domain-Driven Designer ou no português (Designer orientado a domínio) é ainda pouco procurado pelos novos desenvolvedores e para alguns até difícil a sua compreensão. Porém nossa equipe hoje, tentará deixar mais claro para você o tão famoso “Designer orientado a domínio”.
Se você é um aluno ou até um curioso no ramo do desenvolvimento com certeza já se deparou com vários termos que facilitam na hora de organizar o seu processo de desenvolver. Assim como várias outras formas de facilitar o nosso processo de desenvolvimento, o Designer orientado a domínio muda um pouco o foco, pois se trata diretamente ao processo do negócio. Lembrando, “Designer orientado a domínio” não se trata de uma tecnologia ou metodologia.
Desta forma podemos descrever o Domain-Driven Designer como nada mais do que um conjunto de ações (abordagens) com base em conceitos e princípios focados na lógica do processo (domínio) do negócio. O resultado dessas abordagens usadas é a criação do domain model (Modelo de Domínio) um modelo de negócio contendo os dados e as regras que se relacionam entre si no processo. Um exemplo típico de modelo de domínio é o Diagrama de Classes da Unified Modeling Language (UML). E já aproveitando para mostrar a vastidão do campo para um domain model; o modelo pode ser expresso entre várias formas, sendo algumas pelo: Power Point, diagramas em UML como já citamos acima, rascunho de papel, peças de Lego ou até o próprio código da aplicação.
A figura abaixo mostra mostra um mapa com esses conceitos que exibem o relacionamento entre os principais padrões DDD.(O exemplo abaixo é o próprio DDD)
- O código fica menos acoplado e mais coeso;
- O negócio é melhor compreendido por todos da equipe o que facilita o desenvolvimento;
Os programadores conversam usando jargões técnicos (design patterns, abreviações, termos técnicos).
Os especialistas do Domínio usam terminologias específicas de suas áreas
de conhecimento (economia, hotelaria, telecom, ...).
Os computadores conversam linguagens de programação.
Ou seja alguém tem que ceder, então Agile prega que os programadores devem usar a linguagem de domínio como nomenclaturas no código fonte ("ubiquitous language", "system metaphor" na XP), aplicando assim em histórias de usuário, reuniões, e-mails, mensagens instantâneas, planejamento de projeto, documentação de software e código fonte, trazendo assim menor risco de desentendimento, comunicação mais eficiente, conhecimento do domínio armazenado no código fonte e o código fica mais compreensível (manutenibilidade, extensibilidade).
Referencias:
https://www.slideshare.net/
http://www.macoratti.net/11/05/ddd_liv1.htm
Comentários
Postar um comentário