23 . 05 . 2019

Desenvolvimento de software à maneira Wiz

Olá, sou Lucas Mindêllo, Gerente de TI na Wiz e responsável pela definição da visão de desenvolvimento tecnológico. Sendo assim, vou dar um background sobre a Wiz e os desafios que essa visão precisa atacar.

A Wiz vende seguros e produtos financeiros por meio de unidades de negócio. Portanto, temos uma iniciativa que molda a forma como nossa estrutura de vendas funciona.

Para isso, estamos organizados em Squads que atuam em cada unidade de negócio, com necessidades únicas. Como líder do time de desenvolvimento, preciso auxiliá-los com método para realizar o desenvolvimento das soluções numa única visão corporativa e entregar valor a cada sprint. Por sinal, utilizamos Scrum, mas este é um outro assunto.

Como mantemos a governança no nosso desenvolvimento?

Penso que temos que focar em três pilares, um frame que entregue uma mesma visão a todos os desenvolvedores, um processo de desenvolvimento de software e a gestão sobre esses pontos. Neste artigo, vou focar no frame de desenvolvimento.

Para viabilizar esta entrega, precisamos delimitar algumas premissas:

· Utilizamos uma arquitetura de desenvolvimento desacoplado, por meio de microsserviços;

· Delegamos autonomia para todas as squads;

· Precisamos manter um alinhamento de conhecimento dos desenvolvedores;

· Precisamos ter uma governança corporativa de sistemas.

E este frame deve entregar soluções white-label para nossos clientes, baseadas em componentes e com baixo esforço de mudança de look-n-feel.

O que é um componente?

Muito além do conceito de componente de frontend, nós extrapolamos esse conceito para a conexão do backend com o frontend. Fizemos isso de forma que um componente pode ser configurável para qualquer uso similar.

A imagem acima representa um componente simples que possui o CRM e dois bancos de dados como fontes de informação. Neste conceito, entendemos que um padrão de projeto para componentes e páginas é suficiente para prover a governança necessária para o frontend, entretanto precisamos delimitar melhor a nossa arquitetura de backend.

Como endereçamos a governança do backend?

Com objetivo de manter a autonomia das squads e reutilizar a maior parte do nosso código desenvolvido, separamos nossos microsserviços em duas categorias: Wiz Services e Squad Services.

Limitamos no Wiz Services apenas a presença de regras de negócio corporativas, de forma que qualquer unidade de negócio possa utilizar os serviços sem preocupações. Com isso em mente, tivemos que impor uma política de revisão de código e de subida para produção mais rígidas.

Como permitimos aos nossos desenvolvedores que contribuam e evoluam com o Wiz Services, definimos o .NET Core como nosso framework padrão nesta camada.

Para endereçar as responsabilidades de segurança nas conexões entre os elementos, desenvolvemos uma API de SSO baseada em OpenID e token JWT. Fizemos isso de tal forma que a mesma solução de SSO funcione tanto para usuários quanto para sistemas.

Outro serviço auxiliar é o Wiz Log. Essa solução tem o enfoque no registro dos eventos de negócios, com o principal objetivo de armazenar, acompanhar e analisar esses eventos.

Mas o Wiz Log precisa de uma explicação à parte. Pauta para um próximo artigo.

Tudo isso é inútil se não definirmos um padrão de código para nossos projetos de microsserviços.

Qual é o padrão de projeto da Wiz para microsserviços?

Achamos importante separar a nossa aplicação em camadas de domínio, chegando assim na nossa interpretação do DDD (Domain Driven Design). Segmentamos em três camadas: API, Domínio e Infra.

Considero que o sucesso de uma API bem desenhada depende de uma definição de domínio bem-feita. A camada Domínio é onde definimos quais são as entidades que o nosso microsserviço vai representar. Se levarmos a API-CRM como exemplo, a principal entidade é cliente e todo cliente possui alguns atributos comuns a quaisquer unidades de negócio. Portanto, essa é a principal responsabilidade dessa camada.

A camada Infra precisa traduzir as nossas entidades da API para os elementos da nossa fonte de dados. Utilizando novamente a API-CRM como exemplo, nessa camada o cliente pode ser representado por Account e Contact no Salesforce. Dessa forma, se, por qualquer razão, tivermos que integrar na nossa API um outro CRM, basta realizar essa tradução para este outro CRM.

E, finalmente, a camada API, de apresentação, onde expomos nossos endpoints REST. Que, por sinal, estamos utilizando o padrão RESTFull nos nossos microsserviços, o que potencializa a velocidade de desenvolvimento do nosso time.

Conclusão

Penso que estamos no caminho certo para desenvolver soluções robustas, com governança e mantendo a velocidade.

Se você deseja compartilhar o seu conhecimento conosco, entre na página da Wiz no GitHub: https://github.com/wizsolucoes/