Para garantir que a fase de Codificação produzisse o Inventário de Serviços de Arrecadação que atendesse as especificações de design, foram adotados durante a execução
da atividade de Desenvolvimento de Serviço um conjunto de padrões do Catálogo de Padrões de Projetos SOA (ERL et al., 2012). Na atividade de Teste de Serviço, foram aplicadas técnicas de Teste de Unidade, Testes de Integração e Testes de Aceitação afim de validar a qualidade e conformidade dos serviços.
Como resultado direto da atividade do Desenvolvimento de Serviço, novas soluções de software foram criadas e os Serviços de Débito, Serviços de Guias e Serviços de Prefeituras foram migrados para essa nova estrutura. Além disso, os projetos das APIs, contendo as fachadas dos serviços, os contratos e configurações necessárias para implantação autônoma de microsserviços, foram criados para abstrair o acesso aos novos componentes de negócio. Como resultado dos Testes de Serviço, um conjunto de testes que representam as validações do Inventário de Serviço de Arrecadação foram gerados e versionados para usos futuros, tanto no ciclo de implantação, quanto de manutenção de software.
De modo a ilustrar como se deu a construção dos microsserviços do inventário de Arrecadação, os pontos a seguir detalham o uso dos padrões do Catálogo de Padrões de Projetos SOA durante a atividade de Desenvolvimento de Serviço.
Padrão de Inventário de Domínio
Cada Inventário de Serviço foi construído como uma solução de software isolada utilizando o dotnet Framework, a linguagem C# e Templates de Solução da IDE Visual
Studio. Isso permitiu que os projetos de software e bibliotecas fossem organizados de forma
a representar os Contextos Delimitados do Inventário de serviços. A Figura 29 ilustra o Template de Solução do Inventário de Arrecadação (Set.Arrecadacao) e a organização de seus respectivos Contextos Delimitados (Recolhimento e Repasse) em pastas de Solução.
Padrão de Utilitários Transversais aos Domínios
A aplicação desse padrão proporciona o compartilhamento de recursos comuns e agnósticos aos diversos contextos do domínio. Isso evita a reescrita de código e potencializa a reutilização de componentes. A Figura 29ilustra os tipos de recursos compartilhados associados ao Inventário de Arrecadação como banco de dados, cache, filas, modelos de domínio e sistemas de arquivos.
Padrão de Normalização de Serviços
Adotando esse padrão, os Inventários de Serviços foram projetados com ênfase no alinhamento aos seus limites de escopo, respondendo assim, às principais capacidades de negócio de um determinado Contexto Delimitado. Por exemplo, as capacidades de negócio do contexto de Arrecadação foram organizadas em Serviços de Débitos e Serviços de Guias.
Figura 29 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicação Padrão de Utilitários Transversais aos Domínios (fonte-própria).
A Figura30ilustra a criação das pastas de solução Serviços de Débitos e Serviços de Guias dentro da pasta Recolhimento.
Figura 30 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicação do Padrão de Normalização de Serviços (fonte-própria).
Padrão de Fachada de Serviço
No intuito de evitar o acoplamento da lógica de serviço à camada de apresentação e aos recursos de infraestrutura, foi adotado como recurso para construção da API do Serviço o Framework Asp.Net Web API, que fornece componentes e estruturas de Fa- chada que servem como ponto de entrada dos serviços e manipulam as requisições vindas dos clientes consumidores. A Figura 30 ilustra a criação do projeto Set.Recolhimento.Api,
que oferece mecanismos para construção de Fachadas para os serviços de Débito e de Guias.
Padrão de Segregação de Micro-Tarefas
Esse padrão propõe uma abordagem por meio da qual um conjunto de micros- serviços é criado para hospedar as micro-tarefas segregadas, cada uma resolvendo um conjunto distinto de requisições do consumidor. Ou seja, os fluxos de escrita e leitura são segregados em dois componentes de baixa granularidade. Como consequência disso, a aplicação é organizada para preservar o escopo funcional granular de um microsserviço e ganha um grande potencial de escalabilidade. A Figura 31ilustra a criação dos projetos
Set.Debitos.Query e Set.Debitos.Command na pasta de solução Serviços de Débitos. Esses
projetos recebem as Lógicas e Entidades dos serviços migrados do sistema legado. Além disso, a compilação desses projetos geram bibliotecas de código (dotnet) que vão junto ao pacote de publicação.
Figura 31 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicação do Padrão de Segregação de Micro Tarefas (fonte-própria).
Padrão de Camadas de Serviço
O inventário é estruturado em duas ou mais camadas de serviço lógicas, cada uma das quais é responsável por abstrair a lógica do serviço. Nesse sentido, seguindo a arquitetura estabelecida, os serviços foram organizados nas camadas de Entidade, de Tarefa e de Utilitários. Como ilustra a Figura32, os serviços de débitos foram divididos nessas camadas dentro do projeto API Set.Recolhimento.Api.
Padrão de Encapsulamento de Legado
Os serviços legados são encapsulados e sua chamada é intermediada por um contrato, que extrai, encapsula e elimina detalhes técnicos da lógica dos componente legado. A
Figura 32 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicação do Padrão de Camadas de Serviço (fonte-própria).
Figura 33ilustra o exemplo do componente legado GeradorArquivoRemessaLegacy.cs, cuja a lógica não foi reescrita, preservando seu código original. De forma a manter essa lógica legada isolada, o componente legado implementa a Interface IGeradorArquivoRemessa.cs que é injetada na classe ServicoGeracaoArquivoRemessa.cs, impedindo que o novo Serviço conheça detalhes de implementação da lógica legada.
Figura 33 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicação do Padrão de Encapsulamento de Legado (fonte-própria).
Além das técnicas de teste de unidade aplicadas durante o processo de codificação, foram aplicados testes de integração nos inventários de serviço para validação de recursos de serviços. Testes de aceitação também foram aplicados para garantir que os contratos estabelecidos nas APIs estavam em conformidade com a especificação. Para isso, foi necessário usar uma ferramenta cliente REST que oferecesse suporte a testes de escrita. A ferramenta escolhida para essa finalidade foi o POSTMAN 1, que fornece uma interface gráfica que possibilita a escrita de requisições http, além de criar, gerenciar, documentar e executar testes sobre as APIs REST.