Em um projeto existem vários envolvidos, os especialistas do domínio,
desenvolvedores, clientes, patrocinadores e outros interessados no projeto.
Dentre estes envolvidos, os especialistas do negócio têm um grande entendimento do domínio do sistema, mas são limitados quanto aos termos técnicos utilizados para o desenvolvimento de software.
Com os desenvolvedores está situação também ocorre, mas de maneira inversa, tem conhecimento de como o sistema deve ser feito, mas não tem o conhecimento necessário para fazê-lo, falta-lhes conhecimento de como o sistema deve se comportar, como deve agir em cada situação, essas informações serão passadas pelos especialistas do domínio.
De maneira geral, os especialistas descrevem vagamente o que querem, os desenvolvedores se esforçam para entender um domínio novo, e acabam criando abstrações do que entendem, mas isso se torna incompreensível para dos especialistas do domínio. Alguns membros da equipe de desenvolvimento conseguem assimilar melhor o domínio do sistema, porém não tem os detalhes que um especialista oferece e suas traduções sobre o domínio acabam sendo inexatas.
Em um projeto sem uma linguagem de comunicação em comum entre as equipes de desenvolvimento e os especialistas, os desenvolvedores têm que traduzir seus termos para os especialistas e estes para os desenvolvedores, essas traduções podem confundir os conceitos do modelo, tornado fraca a comunicação e dificultando a assimilação do conhecimento. O projeto pode passar por diversos problemas quando os especialistas utilizam seus jargões e os membros da equipe técnica utilizam seus próprios termos para discutir o domínio. Sendo assim nem a linguagem utilizada pelos especialistas nem a dos desenvolvedores pode ser utilizada como uma linguagem comum entre as equipes, porque nenhuma delas atende a todas as necessidades.
Para a construção de um modelo sólido, é preciso uma comunicação clara e o perfeito entendimento dos termos utilizados para descrever o domínio. Com desenvolvedores falando em classes, padrões de projetos, frameworks e UML, torna difícil aos especialistas conseguir entender o que os desenvolvedores querem dizer, e com especialistas utilizando termos técnicos para descrever o problema a ser solucionado dificulta o entendimento dos desenvolvedores. Tanto especialistas, quanto desenvolvedores, estão trabalhando para alcançar um bem comum, o software, por isso tanto um quanto o outro tem que conseguir entender as necessidades da outra equipe para que o objetivo seja alcançado.
Um dos princípios do DDD é o uso de uma linguagem baseada no modelo, o modelo é a representação do domínio, é o artefato comum entre os dois mundos.
Essa linguagem deve ser expressiva para o domínio, essa linguagem é denominada como Linguagem Onipresente, que deve ser empregada durante todo o projeto.
Definir uma linguagem de comunicação não é uma tarefa fácil, o tamanho é a complexidade do domínio estão intimamente relacionados com essa dificuldade. Nem todos os termos da equipe de desenvolvimento e da equipe de especialista do domínio devem ser compartilhados, apenas os mais importantes para o domínio, se todos os termos forem compartilhados isso pode prejudicar a linguagem onipresente dando importância a termos que não são tão significativos para o domínio, devemos nos ater aos termos que tem significado importante para o domínio. Deve-se começar compartilhando os termos mais óbvios, na medida em que estes termos forem sendo utilizados, aqueles que não ficaram claros e termos novos vão sendo estabelecidos. O modelo deve passar de um artefato, para uma parte integral de tudo que os desenvolvedores e especialistas fazem juntos.
Todos os membros das equipes devem entender e utilizar a linguagem onipresente.
Dentre estes envolvidos, os especialistas do negócio têm um grande entendimento do domínio do sistema, mas são limitados quanto aos termos técnicos utilizados para o desenvolvimento de software.
Com os desenvolvedores está situação também ocorre, mas de maneira inversa, tem conhecimento de como o sistema deve ser feito, mas não tem o conhecimento necessário para fazê-lo, falta-lhes conhecimento de como o sistema deve se comportar, como deve agir em cada situação, essas informações serão passadas pelos especialistas do domínio.
De maneira geral, os especialistas descrevem vagamente o que querem, os desenvolvedores se esforçam para entender um domínio novo, e acabam criando abstrações do que entendem, mas isso se torna incompreensível para dos especialistas do domínio. Alguns membros da equipe de desenvolvimento conseguem assimilar melhor o domínio do sistema, porém não tem os detalhes que um especialista oferece e suas traduções sobre o domínio acabam sendo inexatas.
Em um projeto sem uma linguagem de comunicação em comum entre as equipes de desenvolvimento e os especialistas, os desenvolvedores têm que traduzir seus termos para os especialistas e estes para os desenvolvedores, essas traduções podem confundir os conceitos do modelo, tornado fraca a comunicação e dificultando a assimilação do conhecimento. O projeto pode passar por diversos problemas quando os especialistas utilizam seus jargões e os membros da equipe técnica utilizam seus próprios termos para discutir o domínio. Sendo assim nem a linguagem utilizada pelos especialistas nem a dos desenvolvedores pode ser utilizada como uma linguagem comum entre as equipes, porque nenhuma delas atende a todas as necessidades.
Para a construção de um modelo sólido, é preciso uma comunicação clara e o perfeito entendimento dos termos utilizados para descrever o domínio. Com desenvolvedores falando em classes, padrões de projetos, frameworks e UML, torna difícil aos especialistas conseguir entender o que os desenvolvedores querem dizer, e com especialistas utilizando termos técnicos para descrever o problema a ser solucionado dificulta o entendimento dos desenvolvedores. Tanto especialistas, quanto desenvolvedores, estão trabalhando para alcançar um bem comum, o software, por isso tanto um quanto o outro tem que conseguir entender as necessidades da outra equipe para que o objetivo seja alcançado.
Um dos princípios do DDD é o uso de uma linguagem baseada no modelo, o modelo é a representação do domínio, é o artefato comum entre os dois mundos.
Essa linguagem deve ser expressiva para o domínio, essa linguagem é denominada como Linguagem Onipresente, que deve ser empregada durante todo o projeto.
Definir uma linguagem de comunicação não é uma tarefa fácil, o tamanho é a complexidade do domínio estão intimamente relacionados com essa dificuldade. Nem todos os termos da equipe de desenvolvimento e da equipe de especialista do domínio devem ser compartilhados, apenas os mais importantes para o domínio, se todos os termos forem compartilhados isso pode prejudicar a linguagem onipresente dando importância a termos que não são tão significativos para o domínio, devemos nos ater aos termos que tem significado importante para o domínio. Deve-se começar compartilhando os termos mais óbvios, na medida em que estes termos forem sendo utilizados, aqueles que não ficaram claros e termos novos vão sendo estabelecidos. O modelo deve passar de um artefato, para uma parte integral de tudo que os desenvolvedores e especialistas fazem juntos.
Todos os membros das equipes devem entender e utilizar a linguagem onipresente.
 |
Linguagem Onipresente
|
Nenhum comentário:
Postar um comentário