Durante o QCon San Francisco 2012, Ganesh Prasad discutiu sobre suas ideias a respeito de SOA; neste ano, expandiu algumas delas em um artigo sobre sua visão de SOA como um Modelo Orientado a Dependências ("Dependency Oriented Thinking").
SOA é a ciência de analisar e gerenciar dependências entre sistemas. "Gerenciar dependências" significa eliminar dependências desnecessárias e formalizar dependências legítimas para criar contratos de fácil compreensão.
Prasad elaborou o seguinte diagrama que ajuda a ilustrar essa ideia:
Ganesh afirma em seu artigo:
Na camada de negócios (Business layer) o foco em dependências nos força a racionalizar processos e a torná-los mais enxutos. Os processos de negócio precisam ser rastreáveis até a visão da organização (a visão utópica de onde se quer chegar), e até a missão (a estratégia para atingir a utopia da visão), e as atividades necessárias para executar suas estratégias (gestão de produtos, engenharia, marketing, vendas etc.) [...] Na camada de aplicações, tentamos agrupar as operações. Note que a camada de negócios já definiu o agrupamento de operações dentro dos processos. Na camada de aplicações precisamos agrupá-las mais estaticamente.
Quais operações trabalham em conjunto e deveriam ser agrupadas, e quais não? Trata-se de uma questão sobre dependências que precisa ser questionada nessa camada. A resposta, no entanto, será encontrada apenas na camada inferior, a camada de informações. A justificativa é que operações apenas são agrupadas se compartilharem um mesmo modelo de dados. Como se vê, existem dois grupos de modelos de dados: o interno e o externo. Os modelos de dados dentro de qualquer sistema são também conhecidos como "modelos de dados de domínio" e nunca são visíveis a outros sistemas. Em contraste, os modelos de dados externos a um sistema, conhecidos como "modelos de dados de interface", sempre são expostos e compartilhados com outros sistemas.
Recentemente, Ganesh teve a oportunidade de colocar essas ideias em prática em cenários reais. Para cada cenário com falhas, Ganesh sugere que o culpado pelas falhas seja rastreado até um ou mais princípios de dependências violados. Ele acredita que uma organização que segue essas regras acabará alcançando SOA. É claro, tivemos muitos outros exemplos ao longo dos anos em que SOA falhou ou teve sucesso, além de princípios e regras para tornar o uso de SOA bem-sucedido. Os princípios que Ganesh esboça podem ser classificados dentro das quatro camadas em que operam:
- Camada de Negócios: (1) Rastreabilidade (Traceability) - Imponha governança, "garanta que tudo que é realizado faz sentido à visão da organização". (2) Minimalismo - Desafie pressuposições. (3) Visão de domínio (Domain Insight) - Entenda a natureza verdadeira do negócio, "reimagine o negócio a partir dos primeiros princípios".
- Camada de Aplicações: (4) Coesão e acoplamento - "O que funciona em conjunto deve ficar no mesmo grupo, com ligações mínimas entre sistemas distintos". (5) Implementação vs. exposição - "Agrupe operações que compartilham um modelo de dados de domínio e lógica de negócio em produtos, e as que compartilham um modelo de dados de interface em serviços". (6) Variações e versões (Variants and Versions) - "Identifique múltiplas variações concorrentes de cada operação lógica e estabeleça meios para apoiar as mudanças em curso para suas lógicas e interfaces".
- Camada de Informações (Dados): (7) Interno vs. Externo (Inside vs. Outside) - "Distinga o modelo de dados de interface, do modelo de dados de domínio". (8) Conteúdo vs. Contexto - "Separe os elementos de dados principais do modelo de dados de interface de seus elementos qualificadores". (9) Abstrato vs. Concreto - "Crie uma hierarquia de tipos de dados para os elementos de conteúdo e contexto".
- Camada Tecnológica: (10) Agrupamento de dependências (Bundling Dependencies) - "Evite introduzir dependências recentes entre componentes não-relacionados ao implementar a lógica de negócio". (11) Associação tardia (Late Binding) - "Adie dependências inevitáveis até o último momento". (12) A ferramenta correta para o trabalho - "Implemente a lógica usando os mecanismos mais apropriados".
O que você acha desses princípios, e sobre o conceito de ver SOA como um modelo orientado a dependências? Esses princípios poderiam ter ajudado em algum projeto SOA em que você trabalhou? Consideraria utilizá-los hoje, ou modificá-los com base em suas próprias experiências?