Mas o que é Modelo Canônico afinal?

Nos últimos meses tenho visitado várias empresas atuando como consultor SOA e o Modelo Canônico tem se tornado uma grande fonte de dúvidas e confusões.

Mas antes de falar sobre canônico, vamos voltar em um tópico mais ‘básico’ que acredito ser a origem de parte do problema: a Modelagem. É muito comum encontrar problemas de modelagem mas, tratando-se de serviço, a correção destes problemas torna-se um pouco mais complexa. Tal correção não pode ser encarada como um ‘simples’ refactoring. Ao alterar o contrato de um serviço, todos os seus consumidores podem ser afetados. É aí que outros pontos críticos aparecem:

• são conhecidos todos os consumidores daquele serviço?

› se sim, a informação é confiável?

» se sim, o refactoring cross-sistema é viável técnica e financeiramente?

Como a respostas para as perguntas acima dificilmente são ‘sim’, surgem algumas situações:

• quebra ‘inconsciente’ dos clientes:

› desconhecimento do reaproveitamento do serviço (em vários casos, falta de análise de impacto ou até descaso) desconsideram a alteração de outros clientes;

• aumento na complexidade da lógica:

› cenários não identificados na criação do serviço acabam aumentando drasticamente a complexidade na manutenção e no consumo do serviço, levando a um dos próximos tópicos;

• duplicação da lógica:

› diversos fatores, principalmente o tempo, levam à duplicação do serviço, dificultando a manutenção e o reaproveitamento;

• versionamento do serviço:

› finalmente, o versionamento acaba sendo um último recurso na evolução do serviço. Porém deve ser usado com cuidado e planejamento, pois pode dificultar bastante a manutenção;

Uma vez que a alteração na interface dos serviços é complexa, sua modelagem merece atenção redobrada! Para isso é necessário trabalhar juntamente com a área de negócio, buscando sempre utilizar os mesmos termos para que a nomenclatura dos serviços tenha significado para a área de negócio. O Domain Driven Design proposto por Eric Evans (no livro de mesmo nome) ajuda bastante neste sentido!

Uma vez que os serviços e operações (ou capacidades) foram modelados, os parâmetros das operações precisam ser modelados. Esta modelagem NÃO deve levar em conta a nomenclatura dos sistemas já existentes e sim manter o mesmo critério adotado na modelagem dos serviços*. Neste ponto o Modelo Canônico entra na equação, atuando como uma linguagem universal entre os sistemas envolvidos, facilitando o entendimento dos parâmetros dos serviços.

Respondendo a pergunta do título, uma definição simples de Modelo Canônico seria modelo de dados universal utilizado pela camada SOA.

* Nos próximos posts levantarei pontos que devem ser levados em consideração na modelagem do Modelo Canônico que diferem da modelagem tradicional.

[:en]

Nos últimos meses tenho visitado várias empresas atuando como consultor SOA e o Modelo Canônico tem se tornado uma grande fonte de dúvidas e confusões.

Mas antes de falar sobre canônico, vamos voltar em um tópico mais ‘básico’ que acredito ser a origem de parte do problema: a Modelagem. É muito comum encontrar problemas de modelagem mas, tratando-se de serviço, a correção destes problemas torna-se um pouco mais complexa. Tal correção não pode ser encarada como um ‘simples’ refactoring. Ao alterar o contrato de um serviço, todos os seus consumidores podem ser afetados. É aí que outros pontos críticos aparecem:

• são conhecidos todos os consumidores daquele serviço?

› se sim, a informação é confiável?

» se sim, o refactoring cross-sistema é viável técnica e financeiramente?

Como a respostas para as perguntas acima dificilmente são ‘sim’, surgem algumas situações:

• quebra ‘inconsciente’ dos clientes:

› desconhecimento do reaproveitamento do serviço (em vários casos, falta de análise de impacto ou até descaso) desconsideram a alteração de outros clientes;

• aumento na complexidade da lógica:

› cenários não identificados na criação do serviço acabam aumentando drasticamente a complexidade na manutenção e no consumo do serviço, levando a um dos próximos tópicos;

• duplicação da lógica:

› diversos fatores, principalmente o tempo, levam à duplicação do serviço, dificultando a manutenção e o reaproveitamento;

• versionamento do serviço:

› finalmente, o versionamento acaba sendo um último recurso na evolução do serviço. Porém deve ser usado com cuidado e planejamento, pois pode dificultar bastante a manutenção;

Uma vez que a alteração na interface dos serviços é complexa, sua modelagem merece atenção redobrada! Para isso é necessário trabalhar juntamente com a área de negócio, buscando sempre utilizar os mesmos termos para que a nomenclatura dos serviços tenha significado para a área de negócio. O Domain Driven Design proposto por Eric Evans ajuda bastante neste sentido!

Uma vez que os serviços e operações (ou capacidades) foram modelados, os parâmetros das operações precisam ser modelados. Esta modelagem NÃO deve levar em conta a nomenclatura dos sistemas já existentes e sim manter o mesmo critério adotado na modelagem dos serviços*. Neste ponto o Modelo Canônico entra na equação, atuando como uma linguagem universal entre os sistemas envolvidos, facilitando o entendimento dos parâmetros dos serviços.

Respondendo a pergunta do título, uma definição simples de Modelo Canônico seria modelo de dados universal utilizado pela camada SOA.

* Nos próximos posts levantarei pontos que devem ser levados em consideração na modelagem do Modelo Canônico que diferem da modelagem tradicional.