Muita literatura sobre SOA fala sobre a necessidade do negócio estar mais próximo da TI, permitindo alterações rápidas a fim de atender as mudanças do mercado.
Agora pensando na construção de um sistema, no qual a interface se comunicaria apenas via serviços (web services por exemplo). Estes acessariam a camada de aplicação do sistema ou talvez a camada de domínio. Mas este modelo ainda não permitiria rápidas alterações, porque implicaria, por exemplo, em alterações na camada de domínio.
É claro que os serviços teriam a vantagem da integração com outros sistemas, ou ainda algumas padronizações, mas eu perderia, muito provavelmente, em performance e talvez outros requisitos não funcionais que ficariam mais difíceis de implementar.
Gostaria da opinião de vocês se não estou com um visão totalmente errada sobre o assunto…
Bom, eu não concordo muito com a idéia de TODAS as chamadas da interface invoquem serviços. Acho que sua interface poderia chamar diretamente os métodos da sua camada de aplicação que então delega para a camada de domínio. Modelando desta forma, poderias estar expondo sua camada de domínio (com as regras de negócio -> persistência) via serviços para serem integrados com outros sistemas. Outra abordagem que eu acho interessante é que uma aplicação pode ser dividida em módulos, onde cada módulo só pode acessar classes e métodos contidas do seu módulo, e se precisar integrar os módulos então farias a chamada de serviços, desta forma sua aplicação teria um baixo acoplamento entre os módulos.
Espero ter ajudado em algo, vou ficar atendo aos posts aqui para aprender mais!
Não sei ao certo qual a real concepção sobre este argumento onde em SOA o negócio deve estar mais próximo a TI, mas ai vai meu ponto de vista:
Vejo que se falamos de alteração de negócio, isso certamente irá implicar inclusive na revisão de regras dos objetos de domínio. Tendo em vista que estes é que definem todo o comportamento de seu negócio e inclusive dependem de estados válidos para não termos um “sistema em estado inválido” própriamente dito.
Agora se temos alterações em regra de comunicação ou algo parecido, esse sim deve estar implementado no componente.
Por exemplo.
Se por um acaso, é criado um novo tributo a ser pago para o estado onde envolve seu negócio. Isso vai implicar em uma avaliação do seu domínio e não apenas em algum módulo ou componente(chame como quiser).
Agora, se dizemos que seu web service agora ao invés de enviar só o “nome do usuário” deve enviar também o “cpf”. Isso são regras do componente e responsabilidade dele a manipular essas informações(acessando domínio claro);
Domain Driven Design não diz nada sobre a arquitetura da sua aplicação, diz sobre o projeto das classes e outros elementos. Numa arquitetura SOA seus serviços vão possuir camadas de apresentação, negócios e persistência e ali, dentro dele, você aplica DDD.
[quote=mutano]Muita literatura sobre SOA fala sobre a necessidade do negócio estar mais próximo da TI, permitindo alterações rápidas a fim de atender as mudanças do mercado.
Agora pensando na construção de um sistema, no qual a interface se comunicaria apenas via serviços (web services por exemplo). Estes acessariam a camada de aplicação do sistema ou talvez a camada de domínio. Mas este modelo ainda não permitiria rápidas alterações, porque implicaria, por exemplo, em alterações na camada de domínio.
É claro que os serviços teriam a vantagem da integração com outros sistemas, ou ainda algumas padronizações, mas eu perderia, muito provavelmente, em performance e talvez outros requisitos não funcionais que ficariam mais difíceis de implementar.
Gostaria da opinião de vocês se não estou com um visão totalmente errada sobre o assunto…
[/quote]
Sim, com certeza o overhead é maior, mas para isso existem máquinas cada vez mais potentes. Por outro lado, cada assunto fica em seu devido lugar, facilitando o mapeamento de suas regras de negócios na tecnologia. Vc precisa fazer um trade-off e decidir o que é melhor, como tudo na vida…
SOA não exclui DDD, mas também SOA não requer DDD…
