Mais de dois anos após a publicação do meu primeiro post sobre o assunto ele continua atual, apesar de o foco agora estar mais voltado à API’s (o que não deixa de ser SOA, mas isso fica para outro post).
Pensando nisso montei uma palestra onde tentei mostrar a importância do Modelo Canônico e algumas práticas que facilitam a modelagem e evolução do modelo.
Esta palestra foi apresentada no TDC 2014 SP na trilha SOA e BPM, que ocorreu no dia 06/08/2014:
Um fato interessante foi que, na apresentação seguinte, foi comentado justamente que uma das grandes dificuldades na remodelagem da sua API foi entender, com os stakeholders, qual a melhor forma de expressar os dados da empresa. Por mais absurdo que isso possa parecer, o cenário ilustrado aos 8 minutos do vídeo é muito comum.
Acho que acabei não falando no dia, mas sempre comentamos em aula que a modelagem é uma das maiores dificuldades no desenvolvimento e evolução de serviços, e boa parte dessa dificuldade certamente está na modelagem dos dados! Por isso que dou tanta atenção para este tópico.
Mas o que acharam? Ficou mais claro como modelar os dados da sua Camada de Serviços?
Olá Felipe, obrigado pelo material sobre modelo canônico. Gostaria de fazer algumas perguntas. Desculpe se forem óbvias, apesar de trabalhar com arquitetura de software, sou especializado em modelagem de dados.
Nas suas experiências com canônico, que artefato usava para representá-lo? Um XML, um modelo de dados…
Existia alguma camada da arquitetura que fazia a tradução do legado para o canônico? Ex: um sistema legado tem número agência + número conta + dígito verificador num campo só, mas no canônico foi definido que são Campos diferentes.
Qual estratégia usou para convencer as diferentes áreas de negócio, e consequentemente seus desenvolvedores acostumados com um determinado idioma a usarem o idioma agnóstico?
Um grande abraço
Obrigado pelo interesse Fernando!
Sempre que me refiro ao assunto, estou considerando a ‘definição’ do primeiro post sobre o assunto:
Considerando isso ele é definido, tecnicamente, em um Schema (XSD). Caso seja necessário, pode ser visualizado como um diagrama de classes.
Tradicionalmente, a transformação é realizada em um Enterprise Service Bus.
Normalmente é padrão em implementações SOA, para padronizar o consumo de serviços. Seria inviável os consumidores entenderem as estrutura de dados dos diversos sistemas. Desta forma ele é indispensável para os principios de design de serviço Standardized Service Contract, Service Loose Coupling e Service Abstraction ilustrados nos slides.
Apesar de tudo isso, ele deve ser uma iniciativa da Arquitetura/Governança SOA e sua modelagem ser centralizada para minimizar problemas. Desta forma a Arquitetura/Governança SOA devem garantir que os desenvolvedores irão seguir, pelo menos na interface dos serviços de negócio, o Modelo Canônico. O alinhamento dos conceitos comentados no terceiro post do assunto é um pouco mais difícil, sendo respondabilidade dos analistas funcionais/negócio e/ou arquitetura funcional.
Ficou mais claro?
Claro que ficou, sua didática é excelente.
Dada sua explicação, gostaria de fazer mais algunas perguntas.
Dado sua sugestão de centralização, numa empresa grande com muitos sistemas legados e novos, esse schema deveria ter um controle de versão bem cuidado, visto que sofreria manutenções constantes certo? Não fica custoso demais? Não seria melhor ter mini canônicos?
Outra pergunta, quando você convive com uma manutenção nova em um sistema legado, você converte os atributos do legado para o canônico ou deixa como estão, criando apenas o que é novo seguindo o canônico.
Ex. Num sistema bem antigo de financiamento imobiliário, faz-se necessário incluir um novo imposto, o cpmf.
Feito isso, ao se criar novos serviços que vão buscar os dados já armazenados de forma legada e o novo tributo, todos os atributos nesse novo serviço estarão como no canônico?
Um grande abraço
Sim, o ideal é que seu desenvolvimento e manutenção sejam centralizados.
Acredito que sem ele o custo do entendimento seja ainda maior.
Não entendi. O modelo deve ser menos acoplado que um modelo de banco de dados, conforme mencionado no final do segundo post
Uma coisa é o modelo de dados do seu legado, outra é o do seu serviço de negócio. Se o serviço de negócio precisar manipular esta informação, deve ser modelado no canônico, independetemente de como será tratado no Legado e seu Webservice. Desta forma abstraimos o sistema, diminuindo o acoplamento e mantendo a camada soa padronizada (os 3 princípios que comentei nos slides.
Muito obrigado pelos esclarecimentos