Você já deve ter se perguntado ou pensado em como aplicar uma melhor prática atual hoje nesse meio de digital transformation para integração de sistemas com plataformas ESB. Pois bem, hoje no mercado temos várias plataformas para atuação com integração e alguns padrões de mercado ao qual nos permite mesclar trabalhar com domínio – DDD e best practices com integração.

Neste post estarei escrevendo e como trabalharmos com integração de sistemas com Mule ESB, usando as melhores práticas da API LED mesclado com DDD Domain Driven Design.

API LED Conceito

Atualmente as integrações entre sistemas hoje estão interligadas em mundos totalmente complexos, com grande fluxo de dados ao qual as estruturas dos dados constantemente são alteradas.

Devido à essa complexidade o conceito de API LED veio à tona para facilitar as integrações entre esses sistemas, que buscam conectar à uma grande massa de usuários finais (sendo eles próprio ser humano ou um dispositivo eletrônico que tenha a interatividade humana), denominada camada de experiência.

O API LED aplica o conceito da divisão em camadas as responsabilidades das integrações, facilitando a manutenção em cada camada, fornecendo mais controle das entradas e saídas dos processamentos, isolando cada camada, permitindo uma maior coesão e baixo acoplamento, permitindo a facilidade na troca de tecnologias, frameworks e legados/erp.

Abaixo as camadas aplicadas ao API LED:

APIs do Sistema: responsável por interagir com a camada sistema/legado/ERP;

APIs do Processo: responsável pela orquestração das integrações e processamento das informações;

APIs de Experiência: responsável por expor as informações ao usuário final e receber as informações do usuário final, nesse caso onde será redirecionado para a camada de processos;

API LED Diagram

Detalhando um pouco mais sobre cada camada do API LED:

  • APIs Experience: como já mencionado acima essa camada é a responsável por expor informações ao usuário final e também receber informações do usuário final, onde o usuário final não somente será uma pessoa, mas algum equipamento eletrônico como smart watch, smart phone, equipamentos fabris, dentre outros.
  • APIs Processo: é a camada que executa a orquestração como já citado. Ela é responsável pela transformação das mensagens entre a camada de sistemas e a camada de experiência e ou entre camadas de sistema para sistema e experiência para experiência. Pelo api led nenhuma camada de sistema pode acessar diretamente outra camada de sistema ou de experiência ou vice versa, todas as requisições devem passar antes pela orquestração, permitindo um controle melhor das transações e processos que estão sendo executados.
  • APIs Sistema: a camada de sistema é responsável por toda a comunicação com os sistemas legados, ERP’s, banco de dados dentre outros sistemas internos responsáveis por controlar o negócio. As apis de sistemas falam a linguagem do próprio sistema, a comunicação será apenas traduzida no modelo canônico pelas camadas de processos.

Fluxo de navegação entre as camadas

Recapitulando sobre o fluxo das entre as camadas de acordo com os conceitos da API LED, com exceção da camada de processo, as camadas experience e de sistema jamais deverão ter uma comunicação direta entre elas. A camada responsável pela orquestração às demais camadas será e deve sempre ser a camada de processos.

A camada de processos é responsável por receber as requisições da camada de sistema e experiência no modelo canônico e aplicar as regras de negócio traduzindo para a camada de destino, lembrando que sempre importante manter o mínimo de regra de negócio no barramento, se possível zero.

Abaixo estarei mostrando os fluxos permitidos pelo API LED:

Observando a imagem acima, como ficam os fluxos então, os que estão em verde são todos que passam para a camada de processos para a sua devida orquestração, já os que estão em vermelho e fazem ligação direta sem passagem pela camada de processos, estão incorretos, por não passar pela transformação canonizada e pelo orquestrador.

Integrações, API LED com DDD (Domain Driven Design)

Até agora vimos as melhores práticas da API LED no que tange projeto de integrações com Mule ESB. Essa quebra por camadas do API LED já contribui para que os projetos sejam de baixo acoplamento e alta coesão, porém ainda possibilitando que os projetos de integração ainda se tornem monolíticos.

Para evitarmos esse cenário, podemos aplicar ao desenvolvimento das integrações uma mescla de API LED com DDD, isso permitirá além da divisão em camadas, uma divisão por domínios dos seus projetos, rendendo-lhe uma melhor manutenabilidade nos projetos e maior controle nos fluxos de cada domínio.

Além da divisão por domínio no projeto, fazemos a separação dos packages dentro do projeto da integração, sendo as camadas do DDD:

– Infraestrutura: tudo que é necessário para a execução da aplicação;

– Repositório: camada responsável pelas persistências, seja via banco de dados, rest, soap, fila, dentre outros;

– Domínio: contém todas as regras de negócio referente ao domínio;

Arquitetura DDD:

Fonte imagem: Programming Musings by Vikas

https://guptavikas.wordpress.com/2009/12/01/domain-driven-design-an-introduction/

Arquitetura Exemplo aplicado ao DDD em Integrações/Microservices:

Fonte: Domain Driven Design for Services Architecture – ThoughtWorks

Aplicando DDD à API Led com integrações Mule

Com os conceitos de API LED do Mule e o DDD explanados acima, podemos rapidamente definir a arquitetura do projeto de integração que iniciamos acima, que nos dará a visão final de como o nosso projeto ficaria no final, com as camadas divididas e definidas no API LED e a arquitetura voltada ao DDD.

Recapitulando o cenário que tínhamos acima, suponhamos que temos um cenário onde temos que integrar as informações de pedido e cliente de um determinado sistema expondo as informações à uma ponta final que irá utilizar essas informações.

Dentro desse cenário, já podemos extrair os domínios que iremos trabalhar nessa aplicação para iniciarmos nosso DDD:

  • Cliente
  • Pedido

Também já conseguimos extrair as informações de camada para aplicar ao nosso API LED:

  • Sistema Cliente
  • Sistema Pedido
  • Processo Cliente
  • Processo Pedido
  • Experience Cliente
  • Experience Pedido

Após é necessário definir de acordo com os requisitos do projeto, as entradas e saídas, para que possa ser definido os ramls dos projetos de integração (as entradas e saídas), lembrando que cada camada deve ser independente, não conhecendo os demais sistemas, principalmente nas camadas de processo onde o modelo canônico deve ser seguido à risca.

Após as camadas APIs LED definidas como acima juntamente com modelo de domínio, é necessário que nos projetos seja feita a separação das camadas por package ou pode ser feita com módulos do projeto utilizando maven com projeto parent.

Deste modo a arquitetura final do nosso projeto de integração ficaria:

Seguindo esse padrão, terás grande sucesso em seus projetos de integração, garantindo uma fácil manutenabilidade, controle e monitoramento de suas integrações.

Espero que tenham gostado e até breve.

Tiago Canatelli
Últimos posts por Tiago Canatelli (exibir todos)