SOA Corporativa

DDD, SOA

SOA promove flexibilidade ao negócio - foco corporativo, processos - , no entanto, utilizar uma filosofia em que os conceitos do negócio ficam explícitos - DDD, programar para o domínio -, aumenta dramaticamente o nível de flexibilidade possível.

“Fundamentally, DDD is the principle that we should be focusing on the deep issues of the domain our users are engaged in, that the best part of our minds should be devoted to understanding that domain, and collaborating with experts in that domain to wrestle it into a conceptual form that we can use to build powerful, flexible software.” - Eric Evans, infoq.

“…SOA, when it is used well, provides us a very useful way of isolating the domain.” - Eric Evans, infoq.

Artigo interessante: Domain-Driven Design

[ Temos neste blog uma taxonomia de referencia, facilitando a exploração de conceitos, pois existem muitas abordagens conflitantes no mercado. ]

Os serviços básicos de negócio (parecidos com “serviços corporativos” para Erl), por exemplo, encapsulam um domínio, expondo funcionalidades básicas e mais atômicas do negócio (regras de negócio), são coesos e pouco acoplados, normalmente representam um conceito principal do negócio. (Em corporações complexas, dificilmente teremos total controle de duplicação de regras, mas podemos usar algumas abordagens, por exemplo, serviços compostos, para encapsular essas redundâncias.)

Algumas abordagens do livro de Eric Evans podem ajudar na organização desses serviços básicos negócio, por exemplo, distillation na parte de Strategic Design (apenas os serviços importantes para o negócio serão publicados, os serviços essenciais). “Distillation is the process of separating the substances composing a mixture. The purpose of distillation is to extract a particular substance from the mixture. During the distillation process, some byproducts may be obtained, and they can also be of interest. ”, Eric Evans. Strategic Distillation.

Essas abordagens se destinam, na maioria das vezes, a superar limitações humanas, como gerenciar complexidade. Não são incomuns empresas com várias equipes (ou consultorias) desenvolvendo sistemas para automatizar partes diferentes do mesmo subprocesso de negócio.

….

Serviços, em muitos casos, são construídos utilizando objetos. O domínio é “instanciado” também usando objetos (por exemplo, POJOS), objetos devem garantir seu estado consistente (Page Jones) e muitos devem ser persistidos. Neste ponto, começam as dificuldades técnicas, por isso usamos AOP (por exemplo, Spring Framework), EJB 3.0, hibernate; possibilitando focar esforços no domínio (camada de negócio). Algumas abordagens e experiências com uma aplicação JPA e Spring estarão em um próximo post.