DEV Community: Yan Justino

Classificação de Antipadrões em Microsserviços ‐ Parte 03

Yan Justino — Thu, 09 May 2024 00:47:35 +0000

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

1. CONTEXTO

Olá, Dev! Neste post listaremos um catálogo de antipadrões associados a implementação de Microsserviços. Esse catálogo contém uma breve descrição de cada antipadrão, os problemas que eles podem causar e as possíveis soluções que podem ser aplicadas para sanar possíveis problemas de design.

Na parte 01, listamos 5 antipadrões do catálogo de antipadrões de microsserviços. Os antipadrões apresentados foram Wrong Cuts (WC); Cyclic Dependencies (CD); Mega Service (MS); Nano Service (NS); e Shared Librararies (SL).

Já na parte 02 aparesentamos quatro antipadrões: Multiple Service Instances Per Host (MSIPH); Shared Persistence (SP); No API Versioning (NAV); No API Gateway (NAG).

2. ANTIPADRÕES

Nesta terceira e última parte vamos abordar alguns Antipatterns relacionados a monitoria de microsserviços. Eles são: No Health Check (NHC); Local Logging (LL); e Insufficient Monitoring (IM).

✍️ No Health Check (NHC)

Microsserviços são por natureza instáveis, podendo ser implementados em variados locais e ficarem indisponíveis temporariamente ou sob certas condições. Esse antipadrão ocorre quando não existe um endpoint disponível para avaliar o estado operacional do microsserviço.

PROBLEMAS

A ausência de verificações de status regulares através de requisições HTTP, ou a falta de um gateway de API ou sistema de descoberta de serviços, podem sugerir esse antipadrão.
Consumidores do microsserviço podem enfrentar atrasos ou falhas ao receber respostas se o microsserviço estiver fora do ar.

SOLUÇÃO

Incorporar endpoints de verificação de estado nos microsserviços que verifiquem periodicamente sua disponibilidade e capacidade de resposta: Introduzindo endpoints de verificação de estado, microsserviços desativados não processarão requisições, e os consumidores serão informados sobre a indisponibilidade antes de fazerem suas solicitações. Isso evita atrasos e tempos de espera desnecessários.

LEITURAS RECOMENDADAS

Pattern: Health Check API

✍️Local Logging (LL)

Cada microsserviço gera uma grande quantidade de informações que são registradas em sistemas de arquivos diferentes. Essas informações são extremamente úteis para monitoramento e devem ser acessíveis e armazenadas de maneira eficiente. Esse Antipadrão ocorre quando cada microsserviço registra suas informações em um armazenamento local. Indícios desse antipadrão incluem a presença de arquivos de log dentro dos microsserviços, arquivos sendo escritos pelo microsserviço, uso de bancos de dados conscientes de tempo e ferramentas e frameworks de registro.

PROBLEMAS

Logs locais podem ser muito difíceis de agregar e analisar. Isso desacelera o processo de monitoramento proporcionalmente ao número de microsserviços e ao tamanho do log.

SOLUÇÃO

Implementar um sistema de registro distribuído que seja responsável por agregar os logs de todos os microsserviços: Utilizar um mecanismo de registro distribuído permite ter um repositório único de logs, força os microsserviços a usar o mesmo formato de log e simplifica os processos de monitoramento e análise.

LEITURAS RECOMENDADAS

Pattern: Log aggregation

✍️ Insufficient Monitoring (IM)

Dado que os microsserviços fornecidos são frequentemente sujeitos a acordos de nível de serviço (SLA), monitorar seu comportamento e desempenho é crucial. Esse Antipadrão ocorre quando o desempenho e as falhas dos microsserviços não são rastreados. Algumas indicações desse antipadrão incluem o uso de registros locais para alguns microsserviços ou a ausência de endpoints de verificação de saúde.

PROBLEMAS

Um monitoramento insuficiente pode prejudicar as atividades de manutenção em um sistema baseado em microsserviços. Falhas tornam-se mais difíceis de detectar e rastrear problemas de desempenho torna-se mais tedioso. Isso pode até afetar a capacidade de cumprir com o SLA.

SOLUÇÃO

Utilizar uma ferramenta de monitoramento que colete dados de desempenho e estatísticas de falhas de cada microsserviço no sistema: Monitorar todos os aspectos de um sistema baseado em microsserviços fornece uma compreensão completa do comportamento da aplicação. Ele também fornece dados que podem ser usados para melhorar o desempenho e a qualidade de toda a aplicação.

LEITURAS RECOMENDADAS

observability

3. CONCLUSÃO

Nesse post listamos alguns antipadrões associados a microsserviços. Cada antipadrões de microsserviços aponta para desafios comuns que podem comprometer a eficiência, escalabilidade e manutenibilidade de arquiteturas baseadas em microsserviços.

Desde problemas de design, como dependências cíclicas e serviços excessivamente grandes ou pequenos, até questões operacionais como configuração manual, falta de integração e entrega contínuas, e monitoramento insuficiente, cada antipadrão destaca uma área crítica onde as práticas inadequadas podem levar a falhas sistêmicas e degradar a qualidade do serviço.

Reconhecer e refatorar esses antipadrões é essencial para maximizar os benefícios de uma arquitetura de microsserviços, garantindo que eles permaneçam robustos, ágeis e capazes de atender às demandas dinâmicas dos ambientes de TI modernos.

ATENÇÃO!!!

Os artigos referenciados possuem outros antipadrões não abordados nesse post. Recomendo fortemente sua leitura.

REFERÊNCIAS

MENDONCA, N. C. et al. The monolith strikes back: Why istio migrated from
microservices to a monolithic architecture. IEEE Software, Institute of Electrical and
Electronics Engineers (IEEE), v. 38, n. 5, p. 17–22, set. 2021. ISSN 1937-4194.
BOGNER, J. et al. Industry practices and challenges for the evolvability assurance of
microservices: An interview study and systematic grey literature review. Empirical
Software Engineering, Springer Science and Business Media LLC, v. 26, n. 5, jul. 2021.
FORD, N. Software architecture: The hard parts : modern trade-off analyses for
distributed architectures. First edition. Cambridge, Massachusetts: The MIT Press, 2021.
Made available through: Safari, an O’Reilly Media Company. ISBN 1492086843.
NEWMAN, S. Building microservices: Designing fine-grained systems. Second edition.
Beijing: O’Reilly, 2021. ISBN 9781492033998.
Tighilt, R., Abdellatif, M., Trabelsi, I., Madern, L., Moha,
N., and Guéhéneuc, Y.-G. (2023). On the maintenance
support for microservice-based systems through the
specification and the detection of microservice antipatterns.
Journal of Systems and Software, 204:111755. DOI:
https://doi.org/10.1016/j.jss.2023.111755.
Taibi, D. and Lenarduzzi, V. (2018). On the definition of microservice
bad smells. IEEE Software, 35(3):56–62. DOI:
10.1109/MS.2018.2141031.

Caro leitor,

Espero que tenham encontrado insights valiosos na discussão sobre a co-localização de arquivos de teste e código de produção, uma prática que pode transformar significativamente o desenvolvimento de software.

Se você já experimentou essa metodologia em seus projetos, como foi? Quais vantagens e obstáculos você encontrou? Se ainda não tentou, consideraria implementá-la após essa leitura?

Classificação de Antipadrões em Microsserviços ‐ Parte 02

Yan Justino — Wed, 01 May 2024 01:56:40 +0000

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

1. CONTEXTO

Olá, Dev! Neste post estamos listando um catálogo de antipadrões associados a implementação de Microsserviços. Esse catálogo contém uma breve descrição de cada antipadrão, os problemas que eles podem causar e as possíveis soluções que podem ser aplicadas para sanar possíveis problemas de design.

Na primeira parte, listamos 5 antipadrões do catálogo de antipadrões de microsserviços apresentado pelos pesquisadores Taibi, D. and Lenarduzzi, V. (2018)[6] e Tighilt at al (2023)[5]. Os antipadrões apresentados foram Wrong Cuts (WC); Cyclic Dependencies (CD); Mega Service (MS); Nano Service (NS); e Shared Librararies (SL).

2. ANTIPADRÕES

Nesta parte 02 apresentaremos os antipadrões Multiple Service Instances Per Host (MSIPH); Shared Persistence (SP); No API Versioning (NAV); No API Gateway (NAG).

✍️ Multiple Service Instances Per Host (MSIPH)

Acontece quando vários microsserviços são implantados em um único host, que pode ser um container, uma máquina física ou uma máquina virtual. Isso pode parecer conveniente ou eficiente em termos de utilização de recursos, mas traz consigo uma série de desvantagens significativas que podem afetar negativamente a arquitetura e a operação de um sistema baseado em microsserviços.

PROBLEMAS

Impacto na autonomia: com o antipadrão MSIPH, a autonomia é comprometida, pois a falha de um serviço no host pode impactar outros serviços compartilhando o mesmo ambiente.
Impacto na Escala: no contexto do MSIPH, a escalabilidade é afetada, pois escalar um serviço pode exigir mais recursos do host, potencialmente afetando o desempenho de outros serviços que compartilham o mesmo ambiente
Possíveis conflitos dentro do host: Com múltiplos serviços compartilhando o mesmo host, há um risco aumentado de conflitos de recursos, como uso de CPU, memória e I/O. .

SOLUÇÃO

Para evitar os problemas associados ao MSIPH, é recomendável adotar estratégias como:

Containerização: Utilizar containers para encapsular cada serviço individualmente, garantindo que eles operem em ambientes isolados mesmo quando implantados na mesma máquina física ou virtual.
Orquestração de Containers: Usar sistemas de orquestração, como Kubernetes, que gerenciam a implantação, escalonamento e operação de containers de forma eficiente, garantindo que os serviços não interfiram uns com os outros.
Escalonamento Dinâmico: Implementar políticas de escalonamento automático que permitam que cada serviço escale baseado em suas próprias demandas de recursos, sem afetar outros serviços.
Monitoramento e Gerenciamento de Recursos: Adotar ferramentas avançadas de monitoramento e gerenciamento de recursos para detectar e mitigar problemas de contenção de recursos rapidamente.

LEITURAS RECOMENDADAS

✍️ Shared Persistence (SP)

Acontece quando vários microsserviços acessam o mesmo banco de dados relacional. No pior dos cenár.ios, diferentes serviços acessam a mesma entidade do mesmo banco de dados. Um Microsserviço deve ser dono apenas dos dados que ele precisa.

PROBLEMAS

Acoplamento via banco de dados
Diminuição da autonomia da equipe e do serviço

SOLUÇÃO

Isso antipadrão pode levar a uma série de problemas, principalmente relacionados ao acoplamento e à perda de autonomia, como mecionado. Aqui estão algumas das principais soluções para superar este antipadrão:

Bancos de Dados Independentes: A solução mais alinhada com os princípios de microsserviços é que cada serviço tenha seu próprio banco de dados, garantindo assim a total autonomia dos dados. Isso reduz o acoplamento e permite que cada equipe seja responsável por sua parte da infraestrutura de dados, facilitando escalabilidade e manutenção.
Banco Compartilhado com Tabelas Privadas:
Uma alternativa menos isolada, mas ainda viável, é utilizar um banco de dados compartilhado onde cada serviço tem seu próprio conjunto de tabelas. Essas tabelas não são acessíveis por outros serviços, o que ajuda a manter certo grau de isolamento e controle sobre os dados.
Uso de Esquemas de Banco de Dados:
Outra abordagem é o uso de esquemas dentro de um banco de dados compartilhado, onde cada esquema é dedicado a um microsserviço específico. Isso ajuda a manter o isolamento lógico dentro de um mesmo banco de dados físico, facilitando a gestão de permissões e visibilidade de dados.
Integradores de granularidade:
Para casos em que a granularidade vá contra a integridade de dados em um processo que deveria ser transacionalmente simples, a equipe pode deliberar sobre a doção de estratégias integradoras de granularidade.

LEITURAS RECOMENDADAS

✍️ No API Gateway (NAG)

Ocorre quando uma arquitetura de microsserviços é implementada sem um API Gateway, levando a que os clientes tenham que interagir diretamente com os microsserviços individuais. Esse antipadrão pode trazer vários problemas e desafios, especialmente em ambientes de produção com várias interfaces de serviço.

PROBLEMAS

Complexidade para os Clientes: Sem um API Gateway, os clientes precisam conhecer e gerenciar os pontos de acesso de todos os microsserviços que precisam consumir, aumentando a complexidade do lado do cliente.
Dificuldades de Autenticação e Autorização: Cada serviço pode precisar implementar seu próprio mecanismo de autenticação e autorização, o que pode levar a inconsistências e brechas de segurança.
Gestão de Carga e Falhas: Em uma configuração NAG, a lógica para balanceamento de carga e tratamento de falhas pode precisar ser implementada em cada serviço ou no lado do cliente, o que pode complicar o desenvolvimento e a manutenção.
Versionamento de APIs: Gerenciar diferentes versões de API diretamente nos serviços pode tornar-se problemático, especialmente em um ambiente com muitos serviços que evoluem rapidamente.

SOLUÇÃO

Implementar um API Gateway é uma prática comum em arquiteturas de microsserviços modernas devido às suas vantagens em simplificar a gestão de APIs, segurança, e resiliência. Ferramentas populares para este propósito incluem Kong, Apigee e AWS API Gateway, cada uma oferecendo conjuntos robustos de funcionalidades para lidar com as necessidades complexas de microsserviços em ambientes de produção.

Implementação de um API Gateway: A solução mais direta para o antipadrão NAG é introduzir um API Gateway na arquitetura. O API Gateway atua como um ponto de entrada único para todas as chamadas de API, simplificando a interação do cliente com os microsserviços.
Centralização de Autenticação e Autorização: Com um API Gateway, é possível centralizar processos de autenticação e autorização, proporcionando um mecanismo consistente e seguro para controlar o acesso aos serviços.
Balanceamento de Carga e Resiliência: O API Gateway pode gerenciar o balanceamento de carga e implementar padrões de resiliência, como circuit breakers e retries, para lidar com falhas nos serviços de forma transparente.
Gestão de Tráfego e Versionamento: O Gateway permite a gestão eficiente do tráfego e facilita a implementação de estratégias de versionamento de API, permitindo que diferentes versões de serviços sejam acessadas sem impactar os clientes existentes.

LEITURAS RECOMENDADAS

✍️ No API Versioning (NAV)

Refere-se a uma falha de design no desenvolvimento de software onde uma interface de programação de aplicações (API) não é projetada para suportar múltiplas versões simultaneamente. Isso pode criar problemas significativos ao longo do tempo à medida que as APIs evoluem.

PROBLEMAS

Mudanças Que Quebram a Compatibilidade: Sem versionamento, qualquer atualização ou modificação pode potencialmente quebrar as aplicações existentes que dependem da API, levando a malfuncionamentos de software e interrupções no serviço.
Dificuldade na Manutenção: A falta de versionamento torna desafiador manter a compatibilidade com versões anteriores, forçando os clientes a se adaptarem rapidamente às mudanças ou enfrentarem problemas de incompatibilidade.
Barreiras à Adoção: Novos usuários podem hesitar em adotar a API se perceberem que ela muda frequentemente sem um gerenciamento claro de versões, pois isso pode implicar em custos de manutenção mais altos.

SOLUÇÃO

Abordar o antipadrão NAV é crucial para garantir que as APIs permaneçam robustas, confiáveis e fáceis de usar, melhorando assim a sustentabilidade geral dos sistemas de software. Os itens a seguir podem auxiliar a lidar com os problemas listados anteriormente.

Implementar Estratégia de Versionamento: Introduza uma estratégia sistemática de versionamento, como o Versionamento Semântico (SemVer), onde as versões são incrementadas com base na natureza das alterações (maior, menor, correção) para comunicar claramente o impacto das atualizações.
Política de Depreciação de Versões: Estabeleça uma política clara de depreciação para versões antigas, fornecendo aos usuários bastante aviso e orientação sobre a transição para versões mais novas.
Suportar Múltiplas Versões: Mantenha suporte para múltiplas versões de API simultaneamente para permitir que os usuários façam a transição em seu próprio ritmo sem interromper seus sistemas atuais.

LEITURAS RECOMENDADAS

A Mixed-Method Approach to Recommend Corrections and Correct REST Antipatterns

REFERÊNCIAS

MENDONCA, N. C. et al. The monolith strikes back: Why istio migrated from
microservices to a monolithic architecture. IEEE Software, Institute of Electrical and
Electronics Engineers (IEEE), v. 38, n. 5, p. 17–22, set. 2021. ISSN 1937-4194.
BOGNER, J. et al. Industry practices and challenges for the evolvability assurance of
microservices: An interview study and systematic grey literature review. Empirical
Software Engineering, Springer Science and Business Media LLC, v. 26, n. 5, jul. 2021.
FORD, N. Software architecture: The hard parts : modern trade-off analyses for
distributed architectures. First edition. Cambridge, Massachusetts: The MIT Press, 2021.
Made available through: Safari, an O’Reilly Media Company. ISBN 1492086843.
NEWMAN, S. Building microservices: Designing fine-grained systems. Second edition.
Beijing: O’Reilly, 2021. ISBN 9781492033998.
Tighilt, R., Abdellatif, M., Trabelsi, I., Madern, L., Moha,
N., and Guéhéneuc, Y.-G. (2023). On the maintenance
support for microservice-based systems through the
specification and the detection of microservice antipatterns.
Journal of Systems and Software, 204:111755. DOI:
https://doi.org/10.1016/j.jss.2023.111755.
Taibi, D. and Lenarduzzi, V. (2018). On the definition of microservice
bad smells. IEEE Software, 35(3):56–62. DOI:
10.1109/MS.2018.2141031.

Caros leitores,

Se você já experimentou essa metodologia em seus projetos, como foi? Quais vantagens e obstáculos você encontrou? Se ainda não tentou, consideraria implementá-la após essa leitura?

Classificação de Antipadrões em Microsserviços ‐ Parte 01

Yan Justino — Sat, 27 Apr 2024 18:20:15 +0000

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

1. CONTEXTO

Microsserviços tornou-se uma prática no design, construção e entrega de serviços de software baseados em Cloud Computing.
Impulsionada por grandes companhias de tecnologia como Amazon, Netflix e Spotify etc, a Arquitetura de Microsserviços tem sido considerada uma abordagem desejada por startups, pequenas empresas e organizações que cresceram na ordem de centenas de engenheiros. A transição para essa abordagem arquitetural é motivada pela crescente necessidade de escala, robustez dos sistemas, diversificação na adoção de tecnologia e aprimoramentos do paralelismo no desenvolvimento de software.

Ao migrar para Microsserviços, empresas têm buscado uma melhor qualidade de Desempenho, Escalabilidade e Manutenibilidade por meio da decomposição e distribuição de seus sistemas monolíticos em partes que são fáceis de compreender e de manter.
Relatos recentes da indústria têm apresentado diversos casos nos quais equipes de desenvolvimento de software conduziram um processo de reengenharia adotando a Arquitetura de Microsserviços como estratégia de modernização de seus sistemas.

Esses casos revelam que equipes que passam por esse difícil processo, precisam definir qual o nível de granularidade consegue administrar, levando em consideração as necessidades específicas do projeto. Esse passo é importante pois, uma vez o sistema migrado, a equipe precisará lidar com uma série de desafios técnicos como a garantia de disponibilidade; operações transacionais em um sistema distribuído; o aumento da latência; a tolerância a falhas de comunicação entre serviços; o controle de versão; a gestão de uma grande quantidade de recursos e automações etc.

Contudo, determinar uma clara definição de fronteiras na concepção de um Microsserviço tem sido apontado como um dos principais desafios por equipes de desenvolvimento. Isso porque, decompor um sistema e tentar definir “corretamente” sua granularidade, além de ser uma tarefa complexa e extremamente contextual, pode impactar diretamente o uso de recursos computacionais e os atributos de qualidade da aplicação. Nesse contexto, e considerando as vastas interpretações possíveis dos conceitos ligados a Microsserviços, é possível que equipes de desenvolvimento modelem ou construam soluções baseando-se em antipadrões (antipatterns - conhecidos e recorrentes problemas de design).

Investigando os processos de migração para Microsserviços e analisando os resultados alcançados, pesquisadores da França e Canadá [5] apresentaram um catálogo de vários antipadrões de microsserviços, construído através de uma revisão sistemática da literatura, que identificou mais 1.195 artigos através de uma consulta nas principais bases de dados científicas. Nessa mesma linha, uma dupla de pesquisadores filandeses [6] coletaram evidências de más práticas entrevistando 72 profissionais com experiência no desenvolvimento de sistemas baseados em microsserviços.

Com base nessas pesquisas, listaremos um catálogo de antipadrões contendo uma breve descrição de cada um deles, as consequências de sua adoção e possíveis soluções que podem ser aplicadas.

2. ANTIPADRÕES

Dado o número de itens desse catálogo, dividiremos o conteúdo desse artigo em 3 partes. Na parte 01 exploraremos os antipadrões: Wrong Cuts (WC); Cyclic Dependencies (CD); Mega Service (MS); Nano Service (NS); e Shared Librararies (SL).

✍️ Wrong Cuts (WC)

Equipes de software tendem a priorizar aspectos de runtime (desempenho e escala) e infraestrutura quando segmentam uma capacidade de negócio em serviços. Essa abordagem pode ser precoce e impactar a qualidade do sistema. Nesse contexto, esse antipadrão ocorre quando microsserviços são divididos com base em camadas técnicas (Presentation, Business e Data) em vez de uma divisão por capacidade de negócio.

PROBLEMAS

Problemas na separação de responsabilidades
Aumento da complexidade na divisão de dados

SOLUÇÃO

A adoção de métodos de modelagem, como Domain-Driven Design (DDD) e Business Capability Analysis, somados a adoção de métodos de avaliação arquitetural, como o Architectural Trade-off Analysis Method (ATAM) são apontados como estratégias para auxiliar às equipes, ainda nas fases iniciais do projeto, na identificação de possíveis fronteiras de negócio e na validação da proposta arquitetural do sistema.

LEITURAS RECOMENDADAS

Para entender os tipos de design e organização do código sugiro a leitura do post Além dos Templates: Uma Crítica Construtiva à Arquitetura Limpa e a Adaptação Pragmática no Design de Software

✍️ Cyclic Dependencies (CD)

Esse antipadrão ocorre quando múltiplos serviços são circularmante co-dependente e não autônomos, o que vai de encontro diretamente a definição de Microsserviço. Isso pode ser detectado pela existência de chamada circulares entre microsserviços. Por exemplo, A chama B, B chama C, e C chama de volta A.

PROBLEMAS

Dificuldades na manutenção do sistema
Problemans no reuso e isolamento de software

SOLUÇÃO

Realizar revisão e refinamento das formas de relação entre serviços. Recomenda-se a adoção de API Gateway e Service Mesh.

LEITURAS RECOMENDADAS

Qual a diferença entre uma Fachada e um API Gateway?
Esse vídeo do José Roberto Araújo da Emergin Code demonstra a Implementanto AGREGAÇÃO em um API GATEWAY usando OCELOT.

✍️ Mega Service (MS)

Esse antipadrão ocorre quando um microsserviço fornece multiplas capacidades de negócio. Um serviço que possui um número excessivo de responsabilidades de negócio deveria ser decomposto.

PROBLEMAS

Alto acoplamento
Dificuldades na escala do serviço
Dificuldades na manutenção do sistema
Coordenação excessiva entre equipes

SOLUÇÃO

Realizar a decomposição funcional do serviço que possui um número excessivo de responsabilidades de negócio.

LEITURAS RECOMENDADAS

✍️ Nano Service (NS)

Ao contrário do Mega Service, esse antipadrão resulta de uma decomposição de um sistema em uma granularidade muito fina. Isso pode ocorrer quando uma unica capacidade de negócio requer muitos microsserviços trabalhando juntos.

PROBLEMAS

Dificuldades na manutenção do sistema
Explosão no número de componentes
Aumento da complexidade do sistema

SOLUÇÃO

Afim de evitar uma “explosão” no número de componentes no sistema, equipes devem ponderar se novos Microsserviços são de fato necessários. Nesse sentido, equipes podem considerar a adoção de estratégias como Monolitch first aproach ou Coarse-grained Microsserviço. Em caso de gargalos de desempenho em serviços já decompostos, ou em que a adoção de Microsserviço não trouxe os benefícios esperados, a equipe pode deliberar sobre a doção de estratégias integradoras de granularidade [Ford et al., 2021] e seguir por uma abordagem “Monolith Strikes Back” [Mendonça et al., 2021].

LEITURAS RECOMENDADAS

✍️ Shared Libraries (SL)

Esse antipadrão ocorre quando múltiplos microsserviços compartilham bibliotecas e arquivos e esse compartilhamento quebra a autonomia da equipe, fazendo com que ela dependa de uma única fonte para cumprir sua capacidade de negócio.

PROBLEMAS

Acoplamentos excessivos
Coordenação e dependência entre equipes
Controle de dependências mais rigoroso

SOLUÇÃO

Para obter os benefícios do reuso de software, equipes podem ter que lidar com o compartilhamento software através de monorepos, bibliotecas ou a redundância de código clonados em repositórios distintos. Nesse contexto, equipes devem controlar essa redundância e lidar com a necessidade de uma maior coordenação e dependência entre elas. Uma forma de monitorar esse reuso é a adoção de automações para identificação e quantificar a taxa de crescimento de duplicação de código. Uma possibilidade para lidar com o reuso de software é a extração do código duplicado como um serviço autônomo.

LEITURAS RECOMENDADAS

The “I Was Taught to Share” AntiPattern

Obrigado por ler o post. Nos próximos posts iremos explorar os demais antipadrões.

REFERÊNCIAS

MENDONCA, N. C. et al. The monolith strikes back: Why istio migrated from
microservices to a monolithic architecture. IEEE Software, Institute of Electrical and
Electronics Engineers (IEEE), v. 38, n. 5, p. 17–22, set. 2021. ISSN 1937-4194.
BOGNER, J. et al. Industry practices and challenges for the evolvability assurance of
microservices: An interview study and systematic grey literature review. Empirical
Software Engineering, Springer Science and Business Media LLC, v. 26, n. 5, jul. 2021.
FORD, N. Software architecture: The hard parts : modern trade-off analyses for
distributed architectures. First edition. Cambridge, Massachusetts: The MIT Press, 2021.
Made available through: Safari, an O’Reilly Media Company. ISBN 1492086843.
NEWMAN, S. Building microservices: Designing fine-grained systems. Second edition.
Beijing: O’Reilly, 2021. ISBN 9781492033998.
Tighilt, R., Abdellatif, M., Trabelsi, I., Madern, L., Moha,
N., and Guéhéneuc, Y.-G. (2023). On the maintenance
support for microservice-based systems through the
specification and the detection of microservice antipatterns.
Journal of Systems and Software, 204:111755. DOI:
https://doi.org/10.1016/j.jss.2023.111755.
Taibi, D. and Lenarduzzi, V. (2018). On the definition of microservice
bad smells. IEEE Software, 35(3):56–62. DOI:
10.1109/MS.2018.2141031.

Continua...

Caros leitores,

Espero que tenham encontrado insights valiosos na discussão sobre microsserviços e práticas que podem transformar significativamente o desenvolvimento de software.

Você já conhecia esses antipadrões? Identificou algum deles em seu projeto? Deixe seu comentário

Do Conceito à Codificação: Transformando Regras de Negócio em Códigos Confiáveis

Yan Justino — Thu, 07 Mar 2024 02:51:09 +0000

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

As fronteiras da minha linguagem são as fronteiras do meu universo - Ludwig Wittgenstein.

CONTEXTO

A engenharia de software pode empregar muito esforço para alcançar uma clara definição de fronteiras de um sistema. Parte desse trabalho está na concepção de módulos, componentes e seus conectores, bem como as estruturas de alocação que satisfazem um conjunto de requisitos que, mediante determinadas expectativas de qualidade, respondem às demandas do negócio.

Em colaboração com especialitas de negócio, o papel do desenvolvimento é "preencher" as lacunas dessas estruturas de software com comportamentos (ricos) do domínio. Para isso, equipes de desenvolvimento adotam métodos como Business Process Management (BPM), Domain-Driven Design (DDD), Business Capability Analysis etc, para representar contextos do domínio e expressar regras negócio.

Regras de negócio são as diretrizes, critérios, ou condições definidas dentro de uma organização para governar seus processos, operações e transações. Elas abrangem uma ampla gama de áreas podem especificar: critérios de elegibilidade, políticas, processos, padrões etc. Frequentemente regas de negócio são implementadas em sistemas de informação. Esse tipo de automatização permite um monitoramente eficiente dessas regras no cotidiando operacional das organizações.

No entanto, a automatização de regras de negócio em sistemas de informação também demanda um nível de qualidade que garanta confiabilidade nas operações. Nesse sentido, é importante que desenvolvedores implementem os comportamentos de negócio de forma adequada ao ponto de serem livres de efeitos colaterais e fáceis de manter. Caso contrário, o sistema apresentará falhas que podem representar riscos para organização e principalmente para as pessoas.

Comparando as exigências de qualidade sobre sistemas de informação com as práticas de desenvolvimento de software devemos nos questionar:

Como desenvolvedores implementam regras de negócio nos sistemas de informação?
Quais práticas podem ser adotadas para codificar regras de forma a garantir a sua corretude?
Quais as estratégias a equipe de desenvolvimento adota para gerenciar o ciclo de vida das regras no sistema?

Essas questões serão o guia deste post, que tem por objetivo apresentar conceitos e práticas de design desoftware que podem gerar insgihts valiosos para auxiliar desenvolvedores na modelagem, construção e manutenção de regras de negócio em sistemas de informação.

BACKGROUND

Regras de negócio em Domain-Driven Design

No intuito de aproximar a linguagem de negócio ao design de software, Eric Evans, em Domain-Driven Design, propõe a criação de modelos de domínio ricos que representam um "conhecimento destilado" do negócio. Nesse sentido, Evans estabelece os modelos como "a espinha dorsal de uma linguagem utilizada por todos os membros da equipe".

No entanto, a compreensão do que venha ser um modelo rico é muito abstrata e pode ser repleta de equívocos. Um deles é pensar que um modelo rico se resume a uma espécie de contraste à modelos anêmicos (classes desprovidas de comportamento). Uma das consequências dessa visão restrita, é a construção de entidades excessivamente ricas em comportamentos. Segundo os autores do livro Patterns, Principles, and Practices of Domain-Driven Design:

✍🏼 CITAÇÃO
Pessoas novas no DDD tendem a modelar muitos comportamentos. Eles inocentemente acreditam na falácia de que o DDD trata de modelar o mundo real. Posteriormente, eles tentam modelar muitos comportamentos do mundo real de uma entidade.
Scott Millett e Nick Tune

Evans ainda afirma que "as regras de um negócio geralmente não se enquadram na responsabilidade de uma Entidade ou Objeto de valor", uma vez que elas "podem sobrecarregar o significado básico do objeto do domínio". No entanto, ele reitera que 'retirar as regras da camada de domínio é ainda pior'". Para resolver esse impasse, Evans, toma "emprestado o conceito de predicados e cria objetos especializados que avaliam e fornecem como resposta um resultado booleano".

💡SAIBA MAIS
Os conceitos de predicado e resultados booleanos remontam um movimento filosófico-matemático do início do século XX chamado de Virada Linguística. Nesse período, os filósofos adotaram a linguagem como foco central de suas investigações. Pensadores como Frege, Russel e Wittgentein, fazendo uso da lógica e da matemática, procuraram uma abordagem formal para explicar e abstrair os fenômenos linguísticos. Esses estudos têm grande influência sobre como hoje concebemos linguagens de programação de alto nível.

Esses objetos são denominados de Especificações e representam predicados que determinam se o objeto satisfaz ou não alguns critérios. O Código 1 ilustra uma especificação da lógica se o cliente é maior de idade. Ao extrair essa lógica para uma classe própria, amplia-se a expressividade, uma vez que o escopo da classe aponta para um único conceito; amplia-se também a testabilidade, já que essa estrutura possui poucas dependências para ser validada.

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T entity);
}

public class LegalAgeSpecification: ISpecification<Customer>
{
    public bool IsSatisfiedBy(Customer entity) => 
       entity.CalculateAge() >= 18;
}

Código 1. modelo de especificação em C#

A técnica de Especificação é um conceito poderoso em DDD. Contudo, é de certa forma frustrante ver como ela é ocultada no high level conceitual do design. Na visão de blocos de construção do DDD (ver Figura 1) ela não é destacada como os demais conceitos de modelo de domínio. Em seu livro, Evans optou por associar a técnica ao conceito de Objetos de Valor. Demais autores como Vaughn Vernon, Scott Millet e Nick Tune o seguiram nessa mesma linha.

Figura 1. blocos de construção do DDD

Regras de negócio via Design By Contract

As Especificações não são um conceito exclusivos de Evans/Fowler. Duas décadas antes da publicação do DDD, Bertrand Meyer, um mestre em engenharia pela École Polytechnique em Paris, descreveu no capítulo Design By Contract: Building Reliable Software em seu livro Object-Oriented: Software Construction, como ampliar a confiabilidade (Reliability) de software utilizando uma abordagem chamada Design by Contract.

Em resumo, Design by Contract aplica um conjunto de regras de relacionamento entre uma classe e seus clientes (consumidores da classe), como um contrato formal composto por pré-condições e pós-condições, que expressam pra cada parte seus direitos e obrigações. Essa relações se dá por Especificações que visam atender o aspecto de corretude (correctness) da confiabilidade. Para Meyer, "Uma Especificação se dá por Asserções, que são expressões que envolvem e declaram predicados sobre uma entidade, que satisfaçam alguma etapa de execução do software". As asserções podem ser representadas pela seguinte Fórmula de corretude:

\text{\textbraceleft P\textbraceright} \text{ A } \text{\textbraceleft Q\textbraceright} \

Essa formula expressa que qualquer execução de A, iniciada em um estado mantido por P, será concluída em um
estado mantido por Q. Vejamos o seguinte exemplo,

\text{\textbraceleft x >= 9\textbraceright} \text{ x := x + 5 } \text{\textbraceleft x >=13\textbraceright}

Nesse exemplo, se P é um número qualquer (x) maior ou igual a 9; e A é função cujo resultado é uma soma desse número mais o número 5; então Q será um número igual ou superior ao número 13. Nessa perspectiva, "P" representa as pré-condições que expressam as condições sobre as quais uma rotina deve funcionar apropriadamente; enquanto "Q" representa as pós-condições, as quais expressam o estado resultante da rotina executada.

Ainda sobre pré-condições, Meyer afirma que elas são uma obrigação para o cliente e um benefício para o fornecedor. Já as pós-condições, são compreendidas como benefício para o cliente e uma obrigação para o fornecedor.

AVALIAÇÃO

Esta seção discute a implementação de regras de negócio em sistemas de informação, destacando desafios associados ao paradigma imperativo e a importância de práticas como o uso de padrões de projeto e asserções para garantir a corretude e facilidade de manutenção.

Como desenvolvedores implementam regras de negócio nos sistemas de informação?

A resposta para essa questão está intimamente ligada as linguagens, técnicas e recursos adotados pelos programadores. Numa perspectiva geral, entendo que boa parte das principais linguagens na indústria como C, Java, Python, C# tem um forte traço no paradígma Inperativo.

💡SAIBA MAIS
As linguagens imperativas são construídas em torno do conceito de mutação de estado e controle de fluxo. Isso significa que os programas escritos em linguagens imperativas geralmente modificam seus estados através de atribuições a variáveis e usam estruturas de controle como loops (for, while) e condicionais (if-else) para controlar a ordem de execução das instruções.

Apesar de uma parte dessas linguagens oferecerem suporte a outros paradígmas, o traço imperativo ainda tem muita influência sobre como os desenvolvedores escrevem seus programas. O Código 2, ilustrar um exemplo desse tipo de programação.

// Vineyard is a premium wine retailer that caters to both online 
// shoppers and visitors to its physical stores, offering an exquisite 
// selection of wines from around the globe. 
namespace Vineyard.Orders;

public class OrderRegistrationUseCase
{
    private const string Available = "AVAILABLE";
    private const string InTransit = "IN_TRANSIT";

    public Order RegisterOrder(OrderRegistation? command)
    {
        ArgumentNullException.ThrowIfNull(command);

        var customer = CustomerRepository.GetById(command.CustomerId);
        if (customer is null) throw new ArgumentNullException(nameof(customer));
        var isOfLegalAge = DateTime.Now.Year - customer.Birthday.Year >= 18;

        var product = ProductRepository.GetBySku(command.Sku);
        var isValidStatus = product?.Status is Available or InTransit;
        var isNotExpired = product is not null && product.DueDate < DateTime.Now;

        var discount = 0m;

        if (customer.DateOfFirstPurchase.HasValue)
        {
            if (customer.DateOfFirstPurchase < DateTime.Now.AddYears(-1))
            {
                // after 1 year, loyal customers get 10%
                discount = Math.Max(discount, .10m);
                if (customer.DateOfFirstPurchase < DateTime.Now.AddYears(-5))
                {
                    // after 5 years, 12%
                    discount = Math.Max(discount, .12m);
                }
            }
        }
        else
        {
            // first time purchase discount of 15%
            discount = Math.Max(discount, .15m);
        }

        if (customer.IsTheBirthday()) discount += 0.05m;

        var order = new Order(customer, product)
        {
            IsElegible = isOfLegalAge && isValidStatus && isNotExpired,
            Discount = discount
        };

        //TODO : Register in Database

        return order;
    }
}

Código 2. código imperativo

O código C# apresentado anteriormente ilustra uma aplicação da Vineyard, uma loja fictícia especializada na venda de vinhos importados. Nesse código há uma classe chamada OrderRegistrationUseCase que implementa o método RegisterOrder(OrderRegistation command), cuja responsabilidade é registrar a entidade Order. Para isso o serviço faz uso das seguintes regras:

O Pedido deve conter um Cliente
O Cliente deve ter idade igual ou superior a 18 anos
O Pedido deve conter um Produto
O Produto deve estar no status AVAILABLE ou IN_TRANSIT
O Produto não pode estar vencido
Quando a data da primeira compra do Cliente for superior a 1 ano, ele receberá um desconto de 10%.
Quando a data da primeira compra do Cliente for superior a 5 ano, ele receberá um desconto de 12%.
Quando for a primeira compra do Cliente, ele receberá um desconto de 15%.
Se for o aniversário do Cliente, ele receberá mais um acréscimo de 5% de desconto.

Apesar de ilustrativo, esse código baseia-se em uma implementação real, na qual as regras de negócio estão escritas de forma imperativa no código. Isso não é algo raro, e pode ser identificado em diversos sistemas, de diferentes domínios. Nesse tipo de implementação as origens e motivações das regras de negócio que foram parar no código-fonte estão ocultas, possivelmente perdida em algum artefato estático ou na mente de algum especialista.

🤔 OPINIÃO
Particularmente, enxergo o código-fonte para além de um conjunto de instruções de máquina. Ao meu ver ele deveria ser compreendido como um artefato de comunicação entre desenvolvedores na etapa de codificação. Gosto de pensar, que dentre todos os artefatos do ciclo de vida de desenvolvimento de software, o código-fonte é um dos mais dinâmicos. Talvez essas ideias sejam influenciadas por meu apreço por um movimento no qual muitos dos artefatos da engenharia de software são "as a code".

Quais práticas podem ser adotadas para codificar regras de forma a garantir a sua corretude?

Nesta seção ilustraremos o uso de algumas práticas para codificar regras de negócio no software. Para isso, faremos uso de algumas regras defenidas Meyer para o uso de Epecificações. Elas formam um conjunto de orientam a criação de Asserções e partem do princípio que "em nenhuma circustância o corpo de uma rotina deve testar suas precondições". São elas:

Asserções não são mecanismos para validar inputs;
Asserções não são estruturas de controle;
Use Asserções para escrever softwares corretos;
Use Asserções para documentação;

Asserções não são mecanismos para validar inputs

As asserções devem validar apenas o escopo da regra de negócio à qual se propõe. Nesse sentido, crie módulos especializados para tratar validações de input. Uma forma de fazer isso pode ser utilizando padrões como decorator, para isolar o código que irá validar os objetos de input da rotina. o Código 3 ilustra um exemplo de implementação.

public class OrderRegistrationValidation(IOrderRegistrationUseCase service) : IOrderRegistrationUseCase
{
    public Order RegisterOrder(OrderRegistation? input)
    {
        ArgumentNullException.ThrowIfNull(input);

        var customer = CustomerRepository.GetById(input.CustomerId);
        ArgumentNullException.ThrowIfNull(customer);

        var product = ProductRepository.GetBySku(input.Sku);
        ArgumentNullException.ThrowIfNull(product);

        var command = input with { Customer = customer, Product = product };

        return service.RegisterOrder(command);
    }
}

Código 3. exemplo de uso do padrão decorator para validação de inputs

Ao remover as validações de input da classe OrderRegistrationUseCase, diminui-se sua complexidade, fazendo com que o escopo de negócio seja isolado. O Código 4 ilustra o método OrderRegistrationUseCase sem as validações de input.

public class OrderRegistrationUseCase: IOrderRegistrationUseCase
{
    private const string Available = "AVAILABLE";
    private const string InTransit = "IN_TRANSIT";

    public Order RegisterOrder(OrderRegistation? command)
    {
        var customer = command?.Customer!;
        var product = command?.Product!;

        var isOfLegalAge = DateTime.Now.Year - customer.Birthday.Year >= 18;
        var isValidStatus = product.Status is Available or InTransit;
        var isNotExpired = product.DueDate < DateTime.Now;

        var discount = 0m;

        if (customer.DateOfFirstPurchase.HasValue)
        {
            if (customer.DateOfFirstPurchase < DateTime.Now.AddYears(-1))
            {
                // after 1 year, loyal customers get 10%
                discount = Math.Max(discount, .10m);
                if (customer.DateOfFirstPurchase < DateTime.Now.AddYears(-5))
                {
                    // after 5 years, 12%
                    discount = Math.Max(discount, .12m);
                }
            }
        }
        else
        {
            // first time purchase discount of 15%
            discount = Math.Max(discount, .15m);
        }

        if (customer.IsTheBirthday()) discount += .05m;

        var order = new Order(customer, product)
        {
            IsElegible = isOfLegalAge && isValidStatus && isNotExpired,
            Discount = discount
        };

        //TODO : Register in Database

        return order;
    }
}

Código 4. resultado do código sem as validações de input

Asserções não são estruturas de controle

Seguindo o princípio de que "o corpo de uma rotina não deve testar suas precondições", precisamos tornar nosso o código mais declarativo. Para isso removeremos os fluxos de validação para que eles não formem estruturas de controle.Uma das formas possíveis para executar isso é extrair as regras de negócio do método RegisterOrder para métodos novos na classe OrderRegistrationUseCase. O Código 5 ilustra o resultado dessa extração.

public class OrderRegistrationUseCase: IOrderRegistrationUseCase
{
    private const string Available = "AVAILABLE";
    private const string InTransit = "IN_TRANSIT";

    public Order RegisterOrder(OrderRegistation? command)
    {
        var customer = command?.Customer!;
        var product = command?.Product!;

        var order = new Order(customer, product)
        {
            IsElegible = IsOrderEligible(product, customer),
            Discount = CalculateDiscount(customer)
        };

        //TODO : Register in Database

        return order;
    }

    bool IsOrderEligible(Product product, Customer customer) { ... }

    decimal CalculateDiscount(Customer customer) { ... }
}

Código 5.resultado do código sem as regras no corpo do método

Após essas pequenas mudanças, o Código 5 encontra-se bem diferente do Código 2. O método RegisterOrder da classe OrderRegistrationUseCase agora apresenta um escopo mais declarativo. Contudo, como garantir a corretude de nossas regras?

Use Asserções para escrever softwares corretos

Com as extrações relaizadas na classe OrderRegistrationUseCase, foi possível remover as estruturas de controle que estavam no corpo do método, promovendo uma melhor legibilidade ao código. O próximo passo é isolar as Asserções da classe OrderRegistrationUseCase, tornando-as mais atômicas, reutilizáveis e passíveis de teste.Para isso, será adotado o Business Rule Pattern, proposto por Steve Smith. Estes são algums pontos importantes a serem observadas sobre o pattern:

Cada regra deve seguir o Single Responsibility Principle.
Para garantir que a regra siga o Princípio da Responsabilidade Única, tenha em mente o Princípio KISS!
As regras podem ser ordenadas, filtradas ou agregadas conforme necessário.
O motor de regras determina como processar as regras.
A lógica para determinar as prioridades das regras reside no motor de regras.

O primeiro passo para implementar esse padrão, será a remoção do métodos de validação criados no Código 5 para uma estrutura própria. O Código 6 demonstra o resultado da transformação desses métods em Asserções da entidade Customer em uma classe chamada CustomerRules.


public class CustomerRules
{
    public class IsOfLegalAge : ISpecification<Customer>
    {
        public bool IsMatch(Customer customer) => customer.CalculateAge() >= 18;
    }

    public class IsFisrtPurchase : ISpecification<Customer>
    {
        public bool IsMatch(Customer customer) => customer.DateOfFirstPurchase is null;
    }  

    public class IsLoyalCustomers(int years) : ISpecification<Customer>
    {
        public bool IsMatch(Customer customer) => customer.DateOfFirstPurchase < DateTime.Now.AddYears(years * -1);
    }     
}

Código 6.criação das Asserções da entidade Customer

Agora a classe CustomerRules possui uma maior autonomia em relação ao OrderRegistrationUseCase. Cada uma de suas sub-classes implementa a interface ISpecification e possui comportamento livre de efeitos colaterais e são passíveis de testáveis automatizados.

Em seguida, será necessário criar a classe que fará a composição das Asserções para lidar como a regra de negócio. No Padrão Business Rule Pattern esse tipo de classe é denominada Motor de Regras (Rules Engine). O Código 7 demonstra a implementação do Motor de Regas IsOrderEligible, que determina se um pedido é elegível ou não.

public class IsOrderEligible
{
    private static ISpecification<Customer> LegalAgeSpecification => new CustomerRules.IsOfLegalAge();

    public static List<ISpecification<Product>> ProductSpecs  =>
    [
        new ProductRules.IsAvaliableOrInTransit(),
        new ProductRules.IsNotExpired()
    ];

    public static bool Execute(Customer customer, Product product)
    {
        if (!LegalAgeSpecification.IsMatch(customer)) return false;

        foreach (var spec in ProductSpecs)
            if (!spec.IsMatch(product)) return false;

        return true;
    }
}

Código 7. criação do Motor de Regas

Com a extração de todas as regras que estavam acopladas ao caso de uso, o Código 2 foi refatorado para uma versão mais declarativa focada em especificações em vez de instruções. O Código 8 apresenta a versão final da classe OrderRegistrationUseCase após a refatoração.

public class OrderRegistrationUseCase : IOrderRegistrationUseCase
{
    public Order RegisterOrder(OrderRegistationCommand? command)
    {
        var customer = command?.Customer!;
        var product = command?.Product!;

        var order = new Order(customer, product)
        {
            IsElegible = IsOrderEligible.Execute(customer, product),
            Discount = CalculateDiscount.Execute(customer)
        };

        //TODO : Register in Database

        return order;
    }
}

Código 8. resultado final da classe OrderRegistrationUseCase

Quais as estratégias a equipe de desenvolvimento adota para gerenciar o ciclo de vida das regras no sistema?

Reservamos esta seção para apresentar a última das regra listadas na seção anterior. Com ela abordaremos como associar os benefícios das práticas adotadas anterirormente à prática de documentação afim de se obter uma melhor para a manutenção, compreensão e colaboração.

Use Asserções para documentação

Aproveitando o isolamento das Assertions que foram implementadas na seção anteriror, é possível usar todos os recuros do compilador da linguagem C# como comentários e atributos para documentar as regras de negócio. Essa é uma forma de manter uma rastreabilidade e gestão das regras de negócio que foram incluídas no projeto ao longo do tempo mais claras para o time de desenvolvimento. Os Código 9 e Código 10 apresentam um exemplo de documentação das regras.

public class CustomerRules
{
    /// <summary>
    /// No Brasil, o consumo de bebidas alcoólicas por menores de 18 anos
    /// é proibido. A Lei federal 13.106/16 alterou o Estatuto da Criança
    /// e do Adolescente, tornando crime vender, fornecer, servir, ministrar
    /// ou entregar bebida alcoólica a criança ou adolescente.
    /// <see href="https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13106.htm"/>
    /// </summary>
    public class IsOfLegalAge : ISpecification<Customer>
    {
        public bool IsMatch(Customer customer) => customer.CalculateAge() >= 18;
    }

    /// <summary>
    /// Regra de primeira compra definida pelo Gestor do Departamento de Marketing
    /// e acolhida pelo gerente de vendas durante a Black Friday
    /// de 2022.
    /// <see href="https://sistema-interno/features/98098999"/>
    /// </summary>
    [Obsolete("Regra válida até Julho de 2023")]
    public class IsFisrtPurchase : ISpecification<Customer>
    {
        public bool IsMatch(Customer customer) => customer.DateOfFirstPurchase is null;
    }  

    /// <summary>
    /// Implantação do programa de fidelidade após resultados da
    /// Black Friday de 2022 
    /// <see cref="IsFisrtPurchase"/>
    /// <see href="https://sistema-interno/features/99090000"/>
    /// </summary>
    public class IsLoyalCustomers(int years) : ISpecification<Customer>
    {
        public bool IsMatch(Customer customer) => customer.DateOfFirstPurchase < DateTime.Now.AddYears(years * -1);
    }     
}

Código 9. uso de comentários e attributes nas Asserções

/// <summary>
/// Regra de desconto durante o registro do Pedido
/// Os descontos são concedidos nos seguintes casos:
/// 1 - Primeira compra = 15%
/// 2 - Cliente fidelidade com mais de 1 ano = 10%
/// 3 - Cliente fidelidade com mais de 1 ano = 12%
/// 4 - Cliente aniversariantes acréscimo de 5% ao desconto obtido
/// <see cref="CustomerRules.IsFisrtPurchase"/>
/// <see cref="CustomerRules.IsLoyalCustomers"/>
/// <see href="https://sistema-interno/features/99090000"/>
/// </summary>
public class CalculateDiscount
{
    private static List<(ISpecification<Customer> Assert, decimal Discount)> CustomerSpecs =>
    [
        (new CustomerRules.IsFisrtPurchase(), .15m),
        (new CustomerRules.IsLoyalCustomers(1), .10m),
        (new CustomerRules.IsLoyalCustomers(5), 0.12m)
    ];

    public static decimal Execute(Customer customer)
    {
        var discount = 0m;

        foreach (var spec in CustomerSpecs)
        {
            if (spec.Assert.IsMatch(customer))
                discount = Math.Max(discount, spec.Discount);
        }

        if (customer.IsTheBirthday()) discount += .05m;

        return discount;
    }    
}

Código 10. documentação de motor de regas

Há desenvolvedores que não são favoráveis a esse tipo de documentação em código. Contudo, olhando para um contexto no qual uma equipe constantemente precisa alterar regras na aplicação e que essas regras não possuem um registro adequado ou prático, manter essa informação no código proporcionará um pouco de rastreabilidade para esse tipo de mudança, que dificilmente estará explicita em um sistema de versionamento de código.

Mantenha tudo Organizado

Um último aspecto que precisa ser discutido é a organização da estrutura de código para comportar as regras de negócio.A solução aqui apresentada, foi organizada da seguinte forma:

A classes de Asserção foram colocadas junto aos Modelos de Domínio;
Já os motores de regas foram colocados no escopo do caso de uso dentro de uma pasta chamada BusinessRules.
Cada motor foi separado por categoria.

Em nosso exemplo, implementamos dois tipos de padrão de motor: de Eligibility Pattern e Eligibility Pattern. Tomando como referência o conceito de Business Rule Management System (BRMS) apresentado no post de Amit Tlekar. Nele é apresentado outros padrões de motores de regas como Validation Pattern, Authority and Approval Pattern, Legacy Rules Extraction,Scoring & Selection Pattern, Unstructured Big data pattern, Events pattern etc. A Figura 2 ilustra a organização da final da solução.

Figura 2. estrutura de solução

Conclusão

O texto discute a complexidade de definir e implementar regras de negócio em sistemas de informação dentro do campo da engenharia de software. Enfatiza a importância da colaboração entre desenvolvedores e especialistas do negócio para criar estruturas de software que atendam às exigências de qualidade e respondam adequadamente às demandas do negócio. Métodos como Business Process Management (BPM), Domain-Driven Design (DDD), e Business Capability Analysis são destacados como essenciais para mapear e expressar regras de negócio de forma efetiva.

O texto aprofunda-se em conceitos de Domain-Driven Design (DDD) e Design by Contract, propostos respectivamente por Eric Evans e Bertrand Meyer, para ilustrar abordagens na modelagem de domínios ricos e na implementação de regras de negócio com confiabilidade. As especificações são apresentadas como uma técnica para definir critérios claros e verificáveis, enquanto as asserções e contratos formais entre classes e seus consumidores são discutidos como métodos para garantir a corretude e confiabilidade do software.

Por fim, o texto aborda práticas recomendadas para codificar, documentar e manter regras de negócio nos sistemas de informação, destacando a importância de isolamento das validações, uso de asserções para corretude, e documentação adequada para facilitar a manutenção e compreensão. Estas práticas são apontadas como fundamentais para o desenvolvimento de sistemas robustos, flexíveis e alinhados com os objetivos do negócio,ressaltando a necessidade contínua de adaptação e evolução das regras de negócio diante das mudanças do mercado.

Disclaimer

Este texto serve como uma revisão focada nos conceitos de "Design by Contract", com especial atenção à sua implementação na linguagem C#. Embora procuremos abordar os principais pontos e oferecer insights sobre como esses conceitos se aplicam ao desenvolvimento de software, é importante reconhecer que a discussão aqui apresentada não esgota a profundidade e a amplitude do "Design by Contract".

Caros leitores,

Espero que tenham encontrado insights valiosos na discussão sobre o design e organização de código.

Se você já experimentou essas estratégias em seus projetos, como foi? Quais vantagens e obstáculos você encontrou? Se ainda não tentou, consideraria implementá-la após essa leitura?

Seu feedback é crucial para enriquecer essa discussão.

Referências

Você pode acessar o código-fonte desse exemplo clicando aqui

Business Rules

Yan Justino — Sun, 03 Mar 2024 22:25:48 +0000

CONTEXTO

Alcançar uma clara definição de fronteiras de um sistema é um dos grandes desafios no Design Arquitetural de um software. Nessa etapa, são concebidos artefatos como módulos, componetes e seus conectores, bem como, as estruturas de alocação que satisfazem um conjunto de requisitos que, mediante a determinadas expectativas de qualidade, respondam às demandas do negócio.

Nesse contexto, o papel do desenvolvimento é "preencher" as lacunas dessas estruturas de software com comportamentos (ricos) do domínio. Para isso, equipes de desenvolvimento têm adotado métodos como Business Process Management (BPM), Domain-Driven Design (DDD), Business Capability Analysis etc, para identificar possíveis fronteiras e estruturas que representem o domínio do negócio.

Contudo, a adoção desses métodos, por si só, não garante que desenvolvedores implementem esses comportamentos de negócio de forma adequada ao ponto que eles sejam livres de efeitos colaterais e fáceis em sua manutenção. Afim de ilustrar as práticas do Design by Contract, o código a seguir é uma representação de um software que será adaptado ao longo desse post para atender os princípios desse conceito.

// Vineyard is a premium wine retailer that caters to both online shoppers and visitors to its physical stores,
// offering an exquisite selection of wines from around the globe. 
namespace Vineyard.Orders;

public class OrderService
{
    private const string Available = "AVAILABLE";
    private const string InTransit = "IN_TRANSIT";
    private const string Ecommerce = "ECOMMERCE";
    private const string BrickAndMortaStore = "BRICK_AND_MORTA_STORE";

    public Order RegisterOrder(OrderRegistation command)
    {
        var customer = CustomerRepository.GetById(command.CustomerId);
        if (customer is null) throw new ArgumentNullException(nameof(customer));

        var isOfLegalAge = DateTime.Now.Year - customer.Birthday.Year >= 18;

        var product = ProductRepository.GetBySku(command.Sku);

        var isValidStatus = product?.Status is Available or InTransit;

        var isNotExpired = product is not null && 
                           product.DueDate < DateTime.Now;

        var isValidWinery = command.Plataform switch
        {
            BrickAndMortaStore => product is not null &&
                                  CategoryRepository.AccreditedWineries().ContainsKey(product.CategoryId),

            Ecommerce => product is not null &&
                         CategoryRepository.AccreditedWineries().ContainsKey(product.CategoryId) &&
                         !CategoryRepository.WineriesBlockedFromEcommerce().ContainsKey(product.CategoryId),
            _ => true
        };

        var order = new Order(customer, product)
        {
            IsProcessableOrder = isOfLegalAge && isValidStatus && isNotExpired && isValidWinery
        };

        //TODO : Register in Database

        return order;
    }
}

Exemplo. código C#

O código C# apresentado anteriormente ilustra uma aplicação da Vineyard, uma loja fictícia especializada na venda de vinhos importados. Nesse código há uma classe chamada OrderService que impelementa o método RegisterOrder(OrderRegistation command), cuja responsabilidade é registrar a entidade Order. Para isso o serviço faz uso das seguintes regras:

O Pedido deve conter um Cliente
O Cliente deve ter idade igual ou superior a 18 anos
O Pedido deve conter um Produto
O Produto deve estar no status AVAILABLE ou IN_TRANSIT
O Produto não pode estar vencido
Quando a venda for realizada pela loja física, o Produto deve pertencer a uma Vinicula credenciada.
Quando a venda for realizada pelo e-commerce, o Produto, além de pertencer a uma Vinicula credenciada, não pode ser de uma Vinicula bloqueada para esse canal.

Apesar de ilustrativo, esse código basea-se em um caso bem próximo de uma implementação real, no qual as regras de negócio estão escritas de forma imperativa em classes de serviço. Isso não é algo raro, e pode ser identificado em diversos sistemas de domínios diferentes.

Numa perspectiva do DDD, os autores do livro Patterns, Principles, and Practices of Domain-Driven Design, Scott Millett e Nick Tune, afirmam que:

people new to DDD tend to model too much behavior. They innocently by into the fallacy that DDD is about modeling the real world. Subsequently, they try to model many real-world behaviors of an entity...

O código

DESIGN BY CONTRACT

Corretude

A Confiabilidade de um sistema está na sua capacidade de executar, de forma consistente, suas funções conforme esperado. A corretude é uma de suas características da

Especificação

Assertation

Pré-condições e Pós-condições

No capítulo "DESIGN BY CONTRACT: BUILDING RELIABLE SOFTWARE" do seu livro "Object-Oriented: software construction", Bertrand Meyer descorre sobre como expressar especificações, asserções

CONTEXTOS FILOSÓFICOS

Esta é uma leitura opcional no texto. Embora possa oferecer insights interessantes e uma compreensão mais profunda do tema em discussão, reconhecemos que nem todos os leitores têm interesse ou tempo para se aprofundar nesses aspectos. Portanto, sinta-se à vontade para explorar essa seção conforme sua conveniência e interesse pessoal.

Passou-se um pouco mais de um século que as reflexões de Frege e Boole sobre inauguraram uma nova perpectiva matemática e filosófiica sobre a lógica
$QP\implies Q$ .

$p > q$

As regras de negócio em seu código escondem um segredo que remonta uma tradição filosófica que atravessou milênios. Como velhas ruínas, as validações escritas em linguagem de programação, envolvidas por métodos e funções, tem em seu coração os princípios da lógica

Referencias

Além dos Templates: Uma Crítica Construtiva à Arquitetura Limpa e a Adaptação Pragmática no Design de Software

Yan Justino — Sun, 18 Feb 2024 22:14:18 +0000

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

Mas não se preocupe, meu amigo
Com os horrores que eu lhe digo
Isto é somente uma canção
A vida realmente é diferente
Quer dizer, ao vivo é muito pior - Belchior

1. CONTEXTUALIZAÇÃO

As últimas duas décadas foram marcadas por mudanças significativas na forma em que modelamos, construímos, implantamos e mantemos softwares. Testemunhamos na indústria a consolidação do Domain-Driven Design (DDD), a ascensão da Cloud Computing e da Service-Orientation.

Também presenciamos o surgimento de conceitos como Data Lake e Data Mesh, que vieram ampliar os recursos e aspectos voltados à análise e tomada de decisão.Todos esses movimentos da engenharia de software possuem uma forte influência de design centrada nos aspectos de domínio de negócio.

Imerso no contexto dessas transformações, lembro-me de discussões acaloradas nos fóruns de tecnologia sobre quão pobre eram as minhas aplicações modeladas usando conceitos como MVC, Poco, Presentation, BLL e DAL etc, em detrimento a poderosa e rica organização que oferecia o DDD.

Lembro do entusiasmo e da forte influência dos meus gurus e de como em pouco tempo eu também me tornara um (chato) evangelista do Eric Evans, Vaughn Vernon e Scott Millet...

Amadurecer nos traz o benefício e a oportunidade de rir de nós mesmos.

Nas contas do tempo, me recordo de alguns pecados contra o DDD que nós, vigilantes e ávidos acólitos, estávamos prontos pra denunciar. Um deles é proibido de ser pronunciado até hoje: "DDD é um padrão arquitetural". Essa é uma lacuna conceitual que ainda persiste: há uma certa predileção por parte dos desenvolvedores aos padrões táticos do que os aspecto estratégicos do DDD.

Nesse sentido, se criou um certo imbróglio. Desenvolvedores que passaram a adotar DDD tinham uma nítida impressão que estavam fazendo algo diferente: a organização de suas aplicações agora tinham uma estrutura mais semântica, mais expressiva e próxima a linguagem do negócio. No entanto, ter o benefício dessa organização não significava exatamente que a equipe de desenvolvimento tivesse aplicado as abordagens estratégicas do DDD.

Nesse aspecto, dizer que sua aplicação usava um padrão arquitetural chamado DDD parecia, até certo ponto, incoerente. Esse tipo de confusão muitas vezes era respaldada por iniciativas como o DDD N-Layered .NET 4.0 Architecture Guide, um guia que orientava como desenvolvedores poderiam organizar suas aplicações baseando-se em conceitos de DDD. Esse modelo foi amplamente disseminado e até hoje encontramos aplicações estruturadas seguindo essa proposta:

Figura. modelo em camadas aplicando DDD

Posteriormente esse tipo de iniciativa também foi duramente criticada por "reduzir" os aspectos de domínio a uma mera organização de pastas que mais expressavam linguagem de software e não de negócio.

Nothing here talks about what the application does - Uncle Bob.

Nessa linha, o Robert C. Martin (Uncle Bob) em uma emblemática talk na Ruby Midwest 2011, confrontou a comunidade de desenvolvedores Rails questionando-a o porquê de suas aplicações não expressar uma linguagem de negócio em seu Top Level Architecture. O vídeo dessa talk pode ser assistido no link a seguir:

youtube.com

Algo me leva a crer que o Uncle Bob, diante de toda sua experiência e percebendo os conflitos e lacunas conceituais de design da época, vislumbrou a oportunidade de pavimentar o caminho para mais uma de suas publicações, daquela que chamo de "cleanware" - livros com o título "X Limpo".

A Clean Architecture, é uma obra de 2017 que pertence ao conjunto de publicações que representa a visão idealizada de Robert C. Martin (Uncle Bob) sobre princípios e boas práticas no design de software.

Segundo o autor, o objetivo da Clean Architecture é o desenvolvimento de sistemas fáceis de manter, testar, e estender ao longo do tempo, além de promover a separação de responsabilidades em diferentes camadas.

Em pouco tempo a Clean Architecture alcançou uma certa popularidade e influência sobre os projetos de software na industria. Ao meu ver, a fama do autor do "Código Limpo" somada as similaridades de design que os desenvolvedores já adotavam utilizando os padrões táticos de DDD, foram decisivos para o engajamento à Clean Architecture.

No entanto, analisando criticamente os projetos nos quais atuei e que fazem uso da Clean Architecture como ferramenta para organização de software, me parece que há uma compreensão parcial sobre o uso do conceito aplicado as estruturas de aplicações.

Muito embora a obra apresente algumas estratégias de organização de software e ser explicita que elas se aplicam a soluções monolíticas, é perceptível que há uma certa incoerência ao depararmos com várias aplicações adotando apenas uma das estratégias (a mais criticada pelo Uncle Bob, por sinal) e em todo tipo de projeto.

O irônico é que no último capítulos do livro, "O capítulo perdido"(34), o Uncle Bob, fazendo uso de toda sua experiência, alerta:

Todas as orientações que você já leu até agora certamente o ajudarão a projetar softwares melhores [...] Mas acontece que o diabo está nos detalhes de implementação, e é realmente muito fácil cair no último obstáculo se você não pensar nisso um pouco também.

Como ocorre em outros temas na indústria de software, uma grande parcela dos profissionais não visitam as fontes originais de um determinado conhecimento e consomem indiretamente novos conceitos assumindo como verdade aquilo que alguns gurus lhes transmitiu.

Diante disso, esse artigo irá apresentar as estratégias de organização propostas no capítulo 34 do Clean Architecture, e em seguida fará uma breve avaliação sobre a visão apresentada pelo Uncle Bob.

2. DESIGN E ORGANIZAÇÃO DE CÓDIGO

O último capítulo, "O capítulo perdido" (34), da última parte (VI) do livro Clean Architecture apresenta quatro abordagens dedicadas ao design e organização do código. As abordagens são: (a) Pacote por camada, (b) Pacote por recurso, (c) Portas e Adaptadores; e (d) Pacotes por componente. A seguir detalharemos cada uma dessas estratégias.

Pacote por camada

Para Uncle Bob, a estratégia de pacotes por camada é uma das abordagens mais tradicionais. Nelas as camadas devem depender apenas da próxima camada adjacente mais baixa.

Uma das vantagens em adota-la é a rapidez para fazer algo funcionar. Por outro lado, rapidamente as três camadas se mostram insuficientes para conter uma complexidade crescente. Além disso, a estrutura de camadas não expressa nada sobre o domínio de negócio. A figura a seguir ilustra esse modelo de organização.

Figura. representação da estratégia de pacotes por camada (própria)

Pacote por recurso

A estratégia de pacote por recurso é uma divisão vertical, com base em recursos relacionados a conceitos de domínio e Agregações (Aggreate Roots). Nesse modelo, todos os tipos são colocados em um único pacote.

Essa abordagem pode ser conhecida também como Vertial Slice Architecture e tem contornos bem particulares e interessantes na perspectiva de Jimmy Bogard

Para Uncle Bob, a vantagem dessa estratégia é que ela "grita" algo sobre o domínio de negócio. Em contrapartida, ele é muito vago sobre as desvantagens, se limitando a dizer:

Se você leu este livro até aqui, deve estar pensando que podemos fazer muito melhor - e está certo!

A figura a seguir ilustra o modelo de organização de pacote por recurso.

Figura. representação da estratégia de pacotes por recurso (própria)

Portas e Adaptadores

A estratégia de portas e adaptadores é rapidamente apresentada por Uncle Bob, que afirma que o objetivo dessa abordagem é criar arquiteturas onde o código de domínio é independente e separado de detalhes de implementação, como acessos a banco de dados.

Também é conhecida como Arquitetura Hexagonal. A figura a seguir ilustra o modelo de organização de portas e adaptadores.

Figura. representação da estratégia de portas e adaptadores (própria)

Nos últimos anos, esse é o tipo de estrutura mais recorrente que identifico nos projetos. O mais estranho é que mesmo em aplicações que possuam apenas um escopo - e nem precisa ser de negócio, essa estrutura pôde ser identificada.

Na maioria dos casos, esse tipo de implementação em soluções dotnet apresenta um certo relaxamento na relação entre as camadas de apresentação e infraestrutura, ao permitir que detalhes de implementação de infra vazem durante a injeção de dependências, quando orquestrada pela camada web.

Pacote por componente

A estratégia de pacote por componente é nitidamente a abordagem que parece ter a maior empatia de Uncle Bob, uma vez que ela é uma abordagem híbrida que contempla as demais estratégias.

Essa abordagem agrupa todas as responsabilidades relacionadas a um único componente de alta granularidade, mantendo as interfaces de usuários separadas desse único pacote.

Na concepção do autor, podemos "pensar nos componentes bem definidos de uma aplicação monolítica como um degrau rumo a uma arquitetura de microsserviços".

Esse pensamento me remete a uma prática emergente denominada como Modular Monolith. A figura a seguir ilustra o modelo de organização de pacote por componente.

Figura. representação da estratégia de pacotes por componente (própria)

Colocando em perspectiva todas as estratégias de organização propostas pela Clean Architecture podemos ter a seguinte visão comparativa ilustrada na figura a seguir.

Figura. visão comparativa das estratégias (própria)

Diante das abordagens apresentadas, é preciso questionar o quanto as equipes ponderam e racionalizam sobre as decisões de design na hora de construir aplicações? Será que as equipes tem adotado a Clean Architecture apenas como um template de código na busca de organização?

É preciso reforçar que a Clean Architecture não contempla a arquitetura de software como um todo. Na verdade ela representa apenas uma das atividades dentro da etapa de Architectural Design no ciclo de vida da Arquitetura de Software. Para entender mais sobre esse ciclo, recomendo a leitura do livro Designing Software Architectures: A Practical Approach.

3. PONDERAÇÕES SOBRE A CLEAN ARCHITECTURE E SEU AUTOR

Embora a intenção seja promover a flexibilidade, a estrutura proposta pela Clean Architecture pode, paradoxalmente, resultar em rigidez. Alguns críticos argumentam que aderir estritamente a essas regras pode dificultar a adaptação a requisitos de projetos específicos, novas tecnologias ou métodos de desenvolvimento emergentes. O próprio Uncle Bob alerta:

Leave options open where applicable, but be pragmatic, and take into consideration the size of your team, their skill level, and the complexity of the solution in conjunction with your time and budgetary constraints.

Outra crítica comum é que a Clean Architecture pode levar ao overengineering, onde o esforço para manter o software "limpo" supera os benefícios práticos. Isso pode desviar o foco de entregar funcionalidades valiosas para o usuário final para se concentrar excessivamente na estrutura interna do código.

É importante ter em mente que o Uncle Bob é uma figura controversa. Suas obras são cheias de afirmações fortes e que precisam ser ponderadas ao lê-las. Existem capítulos inteiros no Clean Architecture que podem ser contestados à luz da ciência e de pesquisas já validadas antes mesmo da obra ser lançada.

No entanto, é inegavel sua contribuição à indústria e seu poder de engajamento na comunidade de desenvolvedores. Sua larga experiência e senso pragmático aguçado criaram conceitos cujos benefícios já foram igualmente atestados [1][2].

Como em qualquer metodologia ou padrão de design, é importante avaliar as necessidades específicas do projeto e o contexto para determinar a abordagem mais apropriada.

4. CONCLUSÃO

O artigo aborda a evolução das práticas de engenharia de software, com foco na Clean Architecture de Robert C. Martin (Uncle Bob), ressaltando a importância de adaptar os princípios de design ao contexto específico de cada projeto. Ele critica a adoção superficial da Clean Architecture, que muitas vezes resulta em complexidade desnecessária ou overengineering, e destaca a necessidade de uma reflexão crítica sobre as decisões de design.

Além disso, aponta para a relevância de considerar as características únicas de cada equipe e projeto ao aplicar conceitos como Pacote por Camada, Pacote por Recurso, Portas e Adaptadores, e Pacote por Componente. Também enfatiza a figura controversa de Uncle Bob, reconhecendo suas contribuições, mas também alertando para a necessidade de questionar e ponderar suas afirmações.

Em resumo, defende uma abordagem pragmática e adaptável ao design de software, priorizando soluções que atendam às necessidades reais dos projetos e promovam uma linguagem de negócio clara e uma arquitetura sustentável, além de enfatizar a importância de ir além dos templates e regras predefinidas para alcançar uma verdadeira valorização do software para os usuários finais.

Caros leitores,

Espero que tenham encontrado insights valiosos na discussão sobre o design e organização de código.

Se você já experimentou essas estratégias em seus projetos, como foi? Quais vantagens e obstáculos você encontrou? Se ainda não tentou, consideraria implementá-la após essa leitura?

Seu feedback é crucial para enriquecer essa discussão.

Por que "tudo junto" é separado e "separado" é tudo junto? Ou... divagações sobre estrutura de testes em .NET

Yan Justino — Fri, 09 Feb 2024 19:30:45 +0000

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

Atualizado em 10/02/2024

O Design de Software é uma disciplina que procura diminuir a carga cognitiva entre software e os problemas do "mundo real". Muitos conceitos e técnicas podem ser aplicados ao código a fim de se alcançar essa capacidade. Partindo da perspectiva de um desenvolvedor, penso que o design pode se manifestar como uma espécie de "estética" que evidência um fluxo coeso da informação, estruturado em uma visão de solução. Particularmente, gosto quando o código transmite aquele senso de "beleza" que nos faz exclamar:

Uau! Que código bem escrito!!!!

Focando em um recorte específico da organização de código, tenho, por experiência, a impressão de que a qualidade estética aplicada aos artefatos do código de produção (src) não é proporcional a aplicada aos artefatos de testes. Revisitando o passado, percebo que em diversos projetos que pude atuar, havia uma certa falta de "apreço" com a escrita e manutenção dos testes.

Independentemente da sênioridade dos desenvolvedores, e da relevância do projeto, os testes seguiam seu destino cruel em uma jornada rumo a "cafonice". Recorrendo a um MEA CULPA, eu também fui responsável ao longo de minha carreira, por escrever diversas bizarrices em forma de testes (Quem nunca?). Diante disso, uma pulga atrás orelha me faz pensar na seguinte questão:

Como aspectos culturais somados a algumas estratégias de design impactam a evolução do código de teste?

Essa não é uma pergunta simples e talvez mereça uma investigação mais profunda do que essas divagações. Guiado por um impulso extremamente pragmático, direciono a atenção para algumas estratégias de design para entender:

Como as linguagens e frameworks organizam seus softwares de modo a facilitar a manutenção concomitante do código de produção e do código de testes?

Diante disso, me deparei com um tradeoff bem interessante: distanciamento vs aproximação "física" entre o código de testes e o código de produção.

Distanciamento vs Aproximação

Enquanto desenvolvedor dotnet, frequentemente atuo em sistemas que adotam como estratégia o uso de projetos distintos dentro da mesma solução para separar os testes do código de produção. Acredito que essa seja a prática mais comum e recomendada no mundo dotnet. O modelo a seguir ilustra um exemplo de estrutura de solução dotnet.

$/
├─ src/
│  ├─ Production.csproj
│     ├─ ProductionCode.cs
├─ tests/
│  ├─ UnitTests.csproj
│     ├─ TesteCode.cs
├─ .gitignore
├─ README.md
├─ Solution.sln

Contudo, tomando por referência outras Linguagens e Frameworks percebe-se uma abordagem diferente: o código de teste é colocado próximo (na mesma pasta ou arquivo) ao o código de produção, como comumente feito em Go e Rust. O modelo a seguir ilustra como um pacote básico do Go é estruturado.

$/
├─ src/
│  ├─ go.mod
│  ├─ modname.go
│  ├─ modname_test.go
├─ .gitignore
├─ README.md

Vasculhando a rede sobre essa abordagem, percebi um certo pensamento comum entre seus defensores: de que juntar o código de teste ao código de produção pode oferece algumas vantagens para o processo de desenvolvimento e a manutenibilidade do código. Dentre esses benefícios, eles alegam que a abordagem promove: (a) facilidade de Localização, (b) encorajamento a escrita de testes, (c) colaboração, (d) rápida refatoração, (e) estrutura uniforme etc.

Tá... Mas e o C#?

Diante dos potênciais benefícios em aproximar os arquivos de testes com os arquivos de produção, podemos nos perguntar

Quais seriam os ganhos e limitações dessa abordagem aplicada em uma solução dotnet?

Tendo essa questão em mente, convido a darmos um passo desprendido de qualquer pré-conceito para aguçar nosso senso de curiosidade. Para isso, nosso ponto de partida será aplicar a abordagem de unificar o arquivo de testes ao código de produção em um mesmo projeto dotnet. As etapas a seguir detalharão como faremos isso.

1. Criando a solução

Diferentemente, de uma solução prototípica em dotnet onde teríamos um projeto de testes apartado, optamos por não criá-lo, e passamos a escrever nossos arquivos de testes diretamente no projeto de produção, fazendo uso da convenção *.Test.cs.

$/
├─ src/
│  ├─ OrderManagement.csproj/
│     ├─ Order/
│        ├─ OrderItem.cs
│        ├─ OrderItem.Test.cs
├─ .gitignore
├─ README.md
├─ Solution.sln

2. Configurando o projeto

O próximo passo é adicionar ao projeto, os pacotes relativos a execução dos testes. Nesse ponto, o projeto recebeu as referências aos os pacotes do framework xUnit, para executar os testes; e o FluentAssertions, para proporcionar uma maior expressividade as validações. como ilustrar o código de configuração a seguir.

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net8.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
    </PropertyGroup>


    <ItemGroup Label="Test Dependecies">
        <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.6.0"/>
        <PackageReference Include="xunit" Version="2.4.2"/>
        <PackageReference Include="FluentAssertions" Version="6.12.0" />
        <PackageReference Include="xunit.runner.visualstudio" Version="2.4.5">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
            <PrivateAssets>all</PrivateAssets>
        </PackageReference>
        <PackageReference Include="coverlet.collector" Version="6.0.0">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
            <PrivateAssets>all</PrivateAssets>
        </PackageReference>
    </ItemGroup>
</Project>

3. Escrevendo o Teste de Unidade

Criamos um arquivo chamado OrdemItem.cs contendo o código de um record chamado OrdemItem. Fizemos uso de um recurso da linguagem C# chamado partial para dividir os escopos das regras de negócio dos seus testes. O código a seguir ilustra essa implementação.

public partial record OrderItem
{
    public string? Sku { get; init; }
    public uint Quantity { get; init; }
    public decimal Price { get; init; }

    public decimal GetTotalPrice() => Quantity * Price;

    public static implicit operator OrderItem((uint quantity, decimal price) tuple) => new()
    {
        Sku = Guid.NewGuid().ToString(),
        Quantity = tuple.quantity,
        Price = tuple.price
    };
}

O código a seguir, ilustrar o conteúdo do arquivo OrderItem.Test.cs, o qual implementa as especificações do framework de testes xUnit, para testar o record OrderItem.

public partial record OrderItem
{
    [Theory]
    [InlineData(01, 5, 005)]
    [InlineData(05, 5, 025)]
    [InlineData(50, 5, 250)]
    [InlineData(00, 5, 000)]
    internal void get_total_price_method_should_calculate_correctly(uint quantity, decimal price, decimal expected)
    {
        OrderItem item = (quantity, price);     
        item.GetTotalPrice().Should().Be(expected);
    }
}

4. Ajustando a compilação

A fim de evitar que a versão final do software leve arquivos e pacotes desnecessários para o ambiente de produção, fizemos as seguintes intervenções no projeto.

a) adicionamos a tag a seguir, para indicar ao compilador que em versões de release remova os arquivos que estão na convenção **\*.Tests.cs. Isso irá remover da solução todos os arquivos de teste.

<ItemGroup Condition="'$(Configuration)' == 'Release'">
   <Compile Remove="**\*.Tests.cs" />
</ItemGroup>

b) incluímos a condicional '$(Configuration)' != 'Release' na tag que envolve nossas dependências de testes, para indicar ao compilador que as utilize apenas em versões de desenvolvimento.

<ItemGroup Label="Test Dependecies" Condition="'$(Configuration)' != 'Release'">
    ...
</ItemGroup>

A versão final de nosso arquivo de projeto ficou da seguinte forma:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net8.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
    </PropertyGroup>

    <ItemGroup Condition="'$(Configuration)' == 'Release'">
        <Compile Remove="**\*.Tests.cs" />
    </ItemGroup>

    <ItemGroup Label="Test Dependecies" Condition="'$(Configuration)' != 'Release'">
        <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.6.0"/>
        <PackageReference Include="xunit" Version="2.4.2"/>
        <PackageReference Include="FluentAssertions" Version="6.12.0" />
        <PackageReference Include="xunit.runner.visualstudio" Version="2.4.5">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
            <PrivateAssets>all</PrivateAssets>
        </PackageReference>
        <PackageReference Include="coverlet.collector" Version="6.0.0">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
            <PrivateAssets>all</PrivateAssets>
        </PackageReference>
    </ItemGroup>
</Project>

5. Executando os testes

Com a implementação dos passos anteriores, somos capazes de executar nosso teste diretamente no projeto principal, através do comando dotnet test ou pelos recursos da IDE (no meu caso o Rider).

Avaliações

Diante da implementação apresentada, concluímos que não existem empecilhos para um teste conviver junto ao seu código de produção em um projeto dotnet. Percebemos que a adoção do recurso partial possibilita um certo isolamento do teste em nível lógico, e ao mesmo tempo lhe concede um acesso a todo o escopo de visibilidade do código de produção.

Outro aspecto que nos chama atenção é que o uso da convenção **\*.Tests.cs permite uma ordenação "natural" na árvore de arquivos do projeto. Isso facilita a localização do arquivo de testes e pode ser um incentivo para desenvolvedores mante-los organizados. Essa convenção facilita adaptações no processo de compilação para remover os arquivos de testes quando forem enviados para um ambiente produtivo.

Pensando em aspectos de developer experience, sinto um grande conforto e uma sensação de praticidade ao ver os testes tão próximos ao código de produção. Tendo a acreditar que a abordagem tem potencial de favorecer o processo de construção e manutenibilidade de software de forma concomitante aos testes. Contudo, algumas ponderações devem ser feitas.

Considerações Importantes

Alguns aspectos devem ser considerados sobre a adoção dessa abordagem em soluções dotnet:

A abordagem parece ser apropriada para Testes de Unidade. Sendo assim, recomendamos que testes de integração e end-to-end (E2E) mantenham suas estruturas apartadas.
Existe uma carga extra sobre compilador para remover os artefatos de testes do código de produção. Soluções que contenham muitos projetos podem ser impactadas em desempenho.
É preciso investigar o quanto a adoção da abordagem pode impactar as esteiras de pipeline em sua organização. Adaptações nos steps podem ser necessárias.
Analisadores estáticos de código como o SonarQube podem apontar problemas para esse tipo de estrutura em soluções dotnet. O escopo desse artigo não explorou essa vertente.
É preciso ponderar se a abordagem trará um benefício real para a equipe. O engajamento a essa abordagem deve estar associada á um ganho real para a equipe e organização.

De forma geral, a abordagem parece ser muito promissora para o uso em testes de unidade. Contudo, em muitos casos, seguir as convenções da comunidade e as melhores práticas para a linguagem pode ajudar a manter o código organizado, facilitar a manutenção e melhorar a colaboração entre desenvolvedores. Nesse sentido, é preciso balancear os ganhos e limitação na aplicação de qualquer nova técnica.

Conclusão

O texto explora a prática de colocar arquivos de teste na mesma pasta que o código de produção, destacando os benefícios dessa abordagem, como facilidade de localização, incentivo à escrita de testes, e facilidade de refatoração. Além disso, compara essa prática, comum em linguagens como Go e Rust, com a separação tradicional de testes e código de produção em projetos C#.

Para isso, foi conduzida uma experiência em .NET usando *.Test.cs e partial classes para demonstrar a viabilidade e vantagens de manter testes próximos ao código. Apesar dos benefícios percebidos, como praticidade e organização melhorada, o texto pondera sobre desafios potenciais, como impacto no compilador e adaptações na pipeline de CI/CD. Ele conclui que, embora tecnicamente viável, a adoção dessa abordagem deve considerar as práticas da comunidade e as necessidades específicas do projeto

Caros leitores,

Se você já experimentou essa metodologia em seus projetos, como foi? Quais vantagens e obstáculos você encontrou? Se ainda não tentou, consideraria implementá-la após essa leitura?

Seu feedback é crucial para enriquecer essa discussão.

O código desse artigo está disponível Aqui

Testes de integração potencializados por EF, docker e TestContainer

Yan Justino — Sat, 04 Nov 2023 19:12:56 +0000

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

Este artigo foi escrito originalmente em 04 de Novembro de 2023. Ele foi revisado e, é importante lembrar que, ele representa uma visão da época em que foi escrito.

Sim, o desenvolvedor gastará boa parte do seu tempo escrevendo código de testes. Mas isso não quer dizer que ele seja menos produtivo por causa disso - Mauricio aniche

Nessa demo adentramos no universo das práticas modernas de desenvolvimento de software para explorar como o uso estratégico de Entity Framework, Docker e TestContainer pode revolucionar seus processos de testes de integração.

À medida que a tecnologia evolui, nossas metodologias também precisam evoluir, e ao adotar essas ferramentas, podemos aprimorar a produtividade, confiabilidade e a qualidade geral de nossos projetos de software.

Acompanhem-me enquanto percorremos os benefícios que essas tecnologias oferecem e descubram como elas podem elevar seu processo de desenvolvimento a novas alturas. Aproveite o vídeo e compartilhe se gostar...

Testes de integração potencializados por EF, docker e TestContainer - YouTube

Hoje, vamos adentrar o universo das práticas modernas de desenvolvimento de software e explorar como o uso estratégico de Entity Framework, Docker e TestCont...

youtube.com

yanjustino / sql-sartuday-es

Demo para evento SQL Sartuday / ES - 2023

CONTEXTUALIZANDO...

Essa demo é resultado da minha última participação em eventos presenciais: o SQL Sartuday, realizado no sádado dia 28/10/2023. Muitas pessoas me pediram o link da gravação. Infelizmente o evento não registrou as palestras. Sendo assim, decidi gravar o conteúdo da palestra e disponibiliza-lo no canal "Academia .net para zumbis".

Essa canal, com 1.5K de inscritos, é muito especial para mim e estou feliz em poder trazer novos conteúdos para ele. O desejo é reativá-lo e poder contribuir mais com a comunidade.