Aquele blog de SOA

Bons códigos são aqueles desenvolvidos para compreensão humana, e não exclusivamente para compiladores. Para uma compilação bem sucedida, basta o formalismo da linguagem (análise léxica, sintática e semântica); já para a compreensão humana, são necessárias abstrações representativas – preferencialmente originadas do domínio do software, DDD – que auxiliam na percepção, contribuindo com agilidade no desenvolvimento.

Nesse âmbito, compiladores não podem ajudar. Não garantem que um código seja entendido ou manipulado dentro do que seria um esforço viável. No entanto, abstrações (sub-rotinas, classes) aderentes aos conceitos do negócio possibilitam que a evolução do código e o entendimento dos conceitos relativos ao negócio caminhem no mesmo sentido, ou seja, o código só sofre mudanças em grandes proporções se o negócio também mudar significativamente. Boas abstrações possibilitam que mudanças sejam mais orgânicas e naturais para os seres humanos.

“[...] the purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” – Edsger W. Dijkstra

A abstração é uma ferramenta chave, e está intimamente relacionada com o conceito de encapsulamento. Focando nesse aspecto essencial, Page Jones descreve em seu livro “Fundamentals of Object-Oriented Design in UML” os níveis de encapsulamento. Baseando-se nesses níveis, é possível partir de simples linhas de código e chegar ao SOA, em que sub-rotinas encapsulam linhas de código, objetos encapsulam estado e comportamento, e serviços encapsulam objetos ou outros serviços.

Para superar limitações humanas, como lidar com processos complexos e grandes quantidades de informação, SOA fornece uma abstração que indexa e organiza o código, o serviço. Os serviços podem encapsular a lógica de uma tarefa do negócio e também encapsular a lógica referente a conceitos-chaves do domínio.

“But there is a more sensible way to SOA, which maintains loose coupling and drives high cohesion and the secret is this: build your services to implement business processes. Don’t let the data guys scream at you that you need an enterprise data model (you don’t) and don’t let the application portfolio guys demand that you buy everything and stitch it together later (you can’t, this only gets you Frankenstein systems).” Anemic Service Model , Jim Webber, Ph.D. Global Architecture Lead, ThoughtWorks.

Para quem conhece CBD e DbC, isso não é novidade. Talvez, a ênfase em associar serviços ao processo de negócio (serviços representando tarefas em um processo de negócio) seja o diferencial de SOA.

Abstrações aderentes ao negócio proporcionam flexibilidade ao software. No caso de SOA, as abstrações indexam, isolam, organizam conceitos principais e os relacionam com processos de negócio [1][2], tornando as mudanças aceitáveis, mas em um contexto corporativo, não apenas em uma aplicação (os serviços possibilitam isolar a lógica do processo de negócio da lógica dos conceitos principais da organização, facilitando mudanças no processo). Cabe ressaltar que processo de negócio é uma forma natural de representar o funcionamento de uma empresa.

Em outras palavras, SOA torna as mudanças no processo de negócio mais ágeis, uma vez que os serviços deixam a arquitetura dos sistemas aderente ao negócio; se o processo sofrer uma pequena mudança, seus sistemas mudam de forma proporcional. A dissociação da lógica do processo de negócio da lógica do domínio, utilizando interfaces bem definidas, contribui com a flexibilidade. Uncle Bob, em seu blog, sustenta uma visão particular e interessante neste sentido:

“[...] Software developers have known for years that software that changes frequently should be decoupled from software that changes infrequently. When applied to individual programs and systems this principle is sometimes called The Common Closure Principle. When it is applied to the information management of an enterprise, it is called SOA. [...]“

Em muitas empresas sem uma estratégia SOA, simples mudanças de regras de negócio provocam alterações em uma grande quantidade de sistemas (redundância de regras); e pequenas alterações no processo de negócio – para acompanhar a concorrência – são inviabilizadas, pois seria necessário refazer os sistemas envolvidos (regra de processo de negócio misturada com regras da aplicação), normalmente, elaborados para instanciar o processo com uma abordagem “integração espaguete”. Assim, os serviços existem para lidar com a complexidade.

Mesmo com uma ferramenta ESB eliminando a integração ponto a ponto, na ausência de serviços projetados para apoiar processos de negócio (ou seja, sem SOA), ainda teríamos “integração espaguete”, só que agora escondida dentro de uma ferramenta. Vídeo interessante relacionado com SOA sem ESB: Does My Bus Look Big in This?, Martin Fowler & Jim Webber, QCon London 2008. Um post também interessante relacionado: SOA, cuts the Gordian Knot — Not, Uncle Bob.

Serviços servem a propósitos diferentes e desempenham papéis muito distintos, por exemplo:

[1] Durante muito tempo, as empresas foram dirigidas por meio de metas estabelecidas para as áreas funcionais, mas hoje as metas são definidas para os processos essenciais, que constituem um nível fundamental de avaliação de desempenho da organização. (Rummler e Brache, 1990)

[2] A idéia de processo tem estado presente nos textos e nas discussões sobre Administração de Empresas nos últimos anos. É praticamente impossível evitar temas como redesenho de processos, organização por processos e gestão por processos. (José Ernesto Lima Gonçalve, Revista de Administração de Empresas, 2000)