Comments on: Model-Driven Development é Durepoxi

By: pcalcado

pcalcado — Mon, 22 Oct 2007 11:11:28 +0000

Oi, Otávio,

É por aí. Dê uma procurada sobre Camadas e Domain-Driven Design apra entender melhor, alguns bons livros:

- Domain-Driven Design, Eric Evans
- Patterns of Enterprise Application Architecture, Martin Fowler
[]s

By: Otavio

Otavio — Fri, 19 Oct 2007 12:47:29 +0000

Olá Philip, neste post voce citou:
“E como estamos falando de um software OO as regras de negócio estão nos respectivos objetos (grupo e usuario) e não nesse método de serviço.”
Hoje minhas aplicações seguem o seguinte fluxo:
Action –> Service –> Repository –> DAO
Dentre estas camadas transita o meu VO, carregando as informações.
Para tanto em minha classe UsuarioService, é que eu teria o metodo “adicionarUsuario”.
Pois bem, pelo que entendi de suas colocações não só aqui como no GUJ e outros artigos seus, é que o meu Service não deveria existir, e desta forma, diretamente do Action em deveria invocar a classe Grupo(que antes era só o meu VO) e nela ter o metodo “adicionarUsuario”.
É isso mesmo?

By: Paulo Vasconcellos

Paulo Vasconcellos — Fri, 27 Jul 2007 14:34:00 +0000

Caro Philip “Shoes”,

O ponto forte do artigo citado são as 4 razões pelas quais código não é uma boa documentação para processos de negócio. Esqueça (ou perdoe) bullshitagens sobre níveis de maturidade e afins. Simplesmente, não é o caso.

E casos de uso, como documentação, são tão ‘fracos’ quanto código. Tanto que são totalmente ignorados pela EPBE (Eriksson-Penker Business Extensions), extensão da UML que indico para a modelagem de negócios.

Como você, quero crer que DDD e DSL’s caminham para reduzir muito (ou eliminar totalmente) o gap que temos entre negócio e código. Tá na fila: vou mergulhar no tema. Espero em breve ter condições de transcrever seus exemplos a partir do outro ponto de vista.

[]’s

Paulo