A importância da Linguagem Ubíqua para estabelcer uma comunicação mais presente
1,079 views
Skip to first unread message
Thiago Holder
Oct 26, 2010, 3:00:23 PM10/26/10
to dotnetar...@googlegroups.com
Bom dia pessoal,
Há algum tempo eu decidir realizar o meu trabalho de conclusão de curso sobre o Domain Driven Design, porém não irei falar de tudo e sim de um ponto especifico: Linguagem Ubíqua.
Nos momentos em que escrevi a fundamentação teórica e comecei a conviver algumas situações em projetos onde a linguagem falada pelos envolvidos não era tão coerente para o projeto, e o que isso acarretava? Sérios problemas, principalmente na documentação e elaboração até mesmo do código, onde o analista passava algo totalmente o contrário do cliente e o desenvolvedor entendia mais nada, pois só pensava em termos técnicos (sou testemunha disso, quando fiquei batendo na tecla de padrões e ninguem entendia o que eu falava).
Eric Evans destaca que:
Esse trecho comentado em seu livro tem sua questão importante, pois ainda temos um grande problema. Os papeis independentes, é muito comum hoje em dia, ainda encontrar Analistas de Negócios / Sistemas que não sabem programar (leia-se não entende uma leitura no código), por isso fica mais complicado essa separação de papeis. Na minha concepção eu defendo que o programador (para muitos Eng. de Software) ele tem que está mais ativo nas implementações, por tanto separar a suas atividades na compreensão e modelagem da aplicação, na minha concepção, é impressidivel para a evolução do sistema e documentação. E outro ponto é que observei muitos Analistas focarem nas bases, ou seja, primeiro construir modelos de "Entidade Relacional" e depois partir para
Por estes fatos, é que eu encontro problemas ao estabelecer uma comunicação onde esteja presente a linguagem Úbiqua ou Onipresente, pois é dificil para os participantes não terem o seu jargão técnico. E então como uma equipe, ágil, ela pode começar a documentar, testar, codificar... Enfim realizar suas atividades com uma comunicação mais aberta e presente em todos os pontos do projeto. Esteja esta comunicação diante o cliente e até entre a equipe, para que todos possam falar a mesma lingua.
É comum hoje termos alguns desenvolvedores que estão sempre em busca de obter conhecimentos mais elevados em Model Design, porque quando é representado de forma visual para ele fica até mais fácil de transferir aquilo para o código e a participação. E na minha visão, em alguns lugares que já passei eu vejo os Analistas discutirem mais sobre: Tabelas, Campos... Não há uma relação de objetos, do sentido real do sistema para solucionar um problema.
Há algum tempo eu decidir realizar o meu trabalho de conclusão de curso sobre o Domain Driven Design, porém não irei falar de tudo e sim de um ponto especifico: Linguagem Ubíqua.
Nos momentos em que escrevi a fundamentação teórica e comecei a conviver algumas situações em projetos onde a linguagem falada pelos envolvidos não era tão coerente para o projeto, e o que isso acarretava? Sérios problemas, principalmente na documentação e elaboração até mesmo do código, onde o analista passava algo totalmente o contrário do cliente e o desenvolvedor entendia mais nada, pois só pensava em termos técnicos (sou testemunha disso, quando fiquei batendo na tecla de padrões e ninguem entendia o que eu falava).
Eric Evans destaca que:
Qualquer pessoa técnica contribuindo para o modelo deve programar, pelo menos tocar no código, independente do papel desempenhado no projeto. Um responsável por mudar o código deve sempre aprender a expressar o modelo através do código. Todo desenvolvedor deve estar envolvido na discussão sobre o modelo e ter contato com os especialistas do domínio.
Esse trecho comentado em seu livro tem sua questão importante, pois ainda temos um grande problema. Os papeis independentes, é muito comum hoje em dia, ainda encontrar Analistas de Negócios / Sistemas que não sabem programar (leia-se não entende uma leitura no código), por isso fica mais complicado essa separação de papeis. Na minha concepção eu defendo que o programador (para muitos Eng. de Software) ele tem que está mais ativo nas implementações, por tanto separar a suas atividades na compreensão e modelagem da aplicação, na minha concepção, é impressidivel para a evolução do sistema e documentação. E outro ponto é que observei muitos Analistas focarem nas bases, ou seja, primeiro construir modelos de "Entidade Relacional" e depois partir para
Por estes fatos, é que eu encontro problemas ao estabelecer uma comunicação onde esteja presente a linguagem Úbiqua ou Onipresente, pois é dificil para os participantes não terem o seu jargão técnico. E então como uma equipe, ágil, ela pode começar a documentar, testar, codificar... Enfim realizar suas atividades com uma comunicação mais aberta e presente em todos os pontos do projeto. Esteja esta comunicação diante o cliente e até entre a equipe, para que todos possam falar a mesma lingua.
É comum hoje termos alguns desenvolvedores que estão sempre em busca de obter conhecimentos mais elevados em Model Design, porque quando é representado de forma visual para ele fica até mais fácil de transferir aquilo para o código e a participação. E na minha visão, em alguns lugares que já passei eu vejo os Analistas discutirem mais sobre: Tabelas, Campos... Não há uma relação de objetos, do sentido real do sistema para solucionar um problema.
Eu concluo que todos os participantes, assim como o desenvolvedor tem que ter em mente que: "Toda vez onde alguém perceber que um determinado conceito do domínio
possui várias palavras que o represente, essa pessoa deve tentar
readequar tanto a linguagem falada e escrita, quanto o código".
Bom, depois de todo esse resumo o meu TCC se aprofundou nesta questão da "A importância da Linguagem Ubiqua para estabelcer uma comunicação mais presente em todo o projeto". Nessa linguagem estão termos que fazem parte das conversas diárias entre especialistas de negócio e times de desenvolvimento. Todos devem usar os mesmos termos tanto na linguagem falada quanto no código.
A partir desse modelo irei realizar a metodologia com uma pesquisa de campo, entrevistando Analistas e Times de Desenvolvimento, não vou frizar projetos e sim se eles conseguem estabelecer essa comunicação.
Agora peço a ajuda de todos, alguém poderia me dar dicas de formulação que essas perguntas podessem ser feitas para estes participantes?
Atenciosamente
Thiago Holder M. Silva
Bom, depois de todo esse resumo o meu TCC se aprofundou nesta questão da "A importância da Linguagem Ubiqua para estabelcer uma comunicação mais presente em todo o projeto". Nessa linguagem estão termos que fazem parte das conversas diárias entre especialistas de negócio e times de desenvolvimento. Todos devem usar os mesmos termos tanto na linguagem falada quanto no código.
A partir desse modelo irei realizar a metodologia com uma pesquisa de campo, entrevistando Analistas e Times de Desenvolvimento, não vou frizar projetos e sim se eles conseguem estabelecer essa comunicação.
Agora peço a ajuda de todos, alguém poderia me dar dicas de formulação que essas perguntas podessem ser feitas para estes participantes?
Atenciosamente
Thiago Holder M. Silva
Gerson Dias
Oct 26, 2010, 3:31:42 PM10/26/10
to dotnetar...@googlegroups.com
No projeto que estou hoje, tivemos uma situação em que duas classes tinham mesmos comportamentos e os mesmos atributos, porém, representavam conceitos de negócio completamente diferentes nas diferentes partes onde eram usadas no negócio. Inicialmente mantemos em apenas uma classe, para não repetirmos o código.... porém, devido justamente a linguagem do negócio, a manutenção e evolução desta classe ficou mto complicada, pois sempre nos confundiamos com o nome escolhido e para diferenciar os dois "usos" colocamos um enum na classe...
Depois de discutirmos bastante, acabamos duplicando o código (foi um ctrl c ctrl v mesmo), para que o uso ficasse coerente com o negócio. Ou seja, agora podemos evoluir ambos os conceitos separadamente, assim como é no negócio! =)
Linguagem Ubíqua é realmente mto útil para todos! Ou eu sou meio burro e sempre me confundo qdo dois nomes representam uma mesma coisa... :-P
Depois de discutirmos bastante, acabamos duplicando o código (foi um ctrl c ctrl v mesmo), para que o uso ficasse coerente com o negócio. Ou seja, agora podemos evoluir ambos os conceitos separadamente, assim como é no negócio! =)
Linguagem Ubíqua é realmente mto útil para todos! Ou eu sou meio burro e sempre me confundo qdo dois nomes representam uma mesma coisa... :-P
2010/10/26 Thiago Holder <thiago...@gmail.com>
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
Leonardo Bruno Lima
Oct 26, 2010, 5:01:41 PM10/26/10
to dotnetar...@googlegroups.com
Thiago,
Deve-se lembrar que "ler o código" não é o código todo do sistema e sim do domínio, se o domínio estiver coerente com a linguagem oniopresente um "leigo" consegue entender alguma coisa sim.
Abs,
--
Deve-se lembrar que "ler o código" não é o código todo do sistema e sim do domínio, se o domínio estiver coerente com a linguagem oniopresente um "leigo" consegue entender alguma coisa sim.
Abs,
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
--
 |
Leonardo Bruno Lima Microsoft MVP | MCT | MCTS | MCPD Attps Informática [http://www.attps.com.br] +55 (85) 99449511 GMail: lblima.net@gmail.com Live Mail: lblim...@hotmail.com Yahoo Mail: leo.b...@yahoo.com    Blogs: http://lblima.blogspot.com | http://zonadotnet.wordpress.com |
Thiago Holder
Oct 26, 2010, 5:10:52 PM10/26/10
to dotnetar...@googlegroups.com
@Leonardo,
Muito bom a sua observação, realmente eu deixei de frisar neste ponto. A questão de ler um código é entender o domínio. Mas concorda que ao ver o Model-Design um leigo consegue enxergar o sistema, assim estará replicado no código.
Atenciosamente
Thiago Holder M. Silva
Denis Ferrari
Oct 28, 2010, 9:05:33 AM10/28/10
to dotnetar...@googlegroups.com
Quem é o especialista do negócio? Geralmente o cliente.
Quem constrói o projeto? Geralmente um fornecedor qualquer a partir das informações obtidas com esse cliente. O cliente investe R$ p/ passar o conhecimento sobre o domínio p/ a equipe de desenvolvimento. A falta da linguagem onipresente faz com que o código não reflita as informações obtidas com o cliente, pelo menos não diretamente.
Quando um novo fornecedor assume o projeto, ele não só terá que aprender sobre o domínio, mas também terá a árdua missão de traduzir isso no código, afinal de contas, o outro fornecedor fez da forma como entendeu, e não de uma forma onde o domínio ficasse claro. Esse fenômeno faz com que vários fornecedores prefiram reconstruir um software a evoluí-lo, ou seja, o investimento inicial da disseminação de conhecimento por parte do cliente fica ameaçado.
Quando um código reflete o domínio, é possível entender o projeto (pelo menos o domínio) a partir do conhecimento dos especialistas de negócio. Esse fato não só faz com que o investimento na passagem de conhecimento seja duradouro, mas também facilita a evolução do software por outro fornecedor ou até pelo mesmo fornecedor.
Linguagem ubíqua é uma coisa simples de entender e difícil de aplicar. Não só a presença do cliente é indispensável, como também a disciplina do fornecedor ao modelar o domínio.
2010/10/26 Thiago Holder <thiago...@gmail.com>
Rafael Noronha
Nov 6, 2010, 4:50:18 PM11/6/10
to .Net Architects
Thiago,
Qando você tiver uma versão do formulário manda pra mim, que eu tento
criticar.
Também posso contar sobre a experiência do meu time.
Temos aplicado DDD em projetos do setor financeiro, acredito se tratar
de uma experiência bastante relevante :)
[]'s
Qando você tiver uma versão do formulário manda pra mim, que eu tento
criticar.
Também posso contar sobre a experiência do meu time.
Temos aplicado DDD em projetos do setor financeiro, acredito se tratar
de uma experiência bastante relevante :)
[]'s
Reply all
Reply to author
Forward
0 new messages