Permitir o uso de sistemas externos reais, como bancos de dados e serviços Web, em testes unitários, o que também permite reproduzir ambientes de execução realistas e melhorar a cobertura dos testes. 

Gerar dados de teste aleatorizados em cada execução, de modo a aumentar a variabilidade dos dados de entrada e, dessa forma, melhorar a confiabilidade, cobertura e robustez dos testes unitários.

Utilizar extensivamente a espera temporizada, como em Thread.sleep(), em testes concorrentes, de modo a estabilizar falhas relacionadas com temporização e reduzir a incidência de comportamentos intermitentes.

Lançar mão de implementações simuladas (mockups) em lugar do acesso ao relógio local e a serviços externos, isolando a unidade em teste e garantindo que cada teste seja independente de efeitos externos.

Declarar PixTransfer como subclasse tanto de AbstractTransaction quanto de outra classe concreta responsável por logging, resolvendo eventuais conflitos de métodos por meio de sobrescrita explícita.

Declarar PixTransfer como subclasse de AbstractTransaction e fazendo-a implementar, simultaneamente, Auditable e Reversible, sobrescrevendo explicitamente eventuais métodos default conflitantes definidos nas interfaces.

Declarar Auditable e Reversible como classes abstratas em vez de interfaces, permitindo que PixTransfer herde múltiplas implementações e confiando na ordem de resolução de métodos da linguagem para tratar conflitos.

Declarar PixTransfer de forma que ela simplesmente implemente Auditable e Reversible, uma vez que a herança de interfaces permite reutilização implícita de estado e comportamento equivalente à herança de uma classe abstrata.

No lado do cliente, o que é suficiente para verificar se as requisições estão corretas e evitar que requisições malformadas sejam enviadas para o servidor, melhorando a usabilidade e eliminando tráfego desnecessário.

No API Gateway, para verificar a conformidade com o esquema de requisições, evitando a necessidade de verificação de erros pelo servidor e padronizando a validação entre os vários microsserviços. 

No lado do cliente para verificar regras de formatação, melhorando a usabilidade e reduzindo tráfego desnecessário, assim como no lado servidor para garantir segurança e conformidade com a interface do serviço.

No lado do servidor, em se tratando de requisições a APIs publicamente acessíveis, ao passo que requisições internas entre os microsserviços da aplicação podem ser validadas apenas pelo microsserviço chamador.

gerenciar os contêineres em um nó, garantindo que todos os contêineres descritos na especificação de pods do nó estejam ativos e funcionando corretamente. 

escalonar contêineres para executarem em pods específicos visando à otimização do uso de recursos e ao balanceamento de carga em um nó.

armazenar informações de estado do cluster para uso na recuperação dos nós após a ocorrência de falhas.

controlar o mapeamento de endereços IP e números de porta para tornar os contêineres acessíveis externamente.

Controlar, dinamicamente, a quantidade de máquinas virtuais utilizadas para executar o número de réplicas de um microsserviço necessárias para atender a carga de trabalho gerada pelos clientes.

Aumentar ou reduzir a quantidade de recursos alocados para os pods que executam as instâncias de um determinado microsserviço, de modo a atender a demanda atual de carga de trabalho gerada pelas aplicações.

Realizar o ajuste automático da quantidade de réplicas de pods que executam um determinado microsserviço com base em métricas de uso e na carga de trabalho atual gerada pelos clientes do microsserviço.

Garantir a escalabilidade de um microsserviço por meio do ajuste dinâmico da quantidade de pods utilizados para executá-lo, com base no monitoramento de métricas de desempenho e do volume de carga de trabalho.

a tomada de decisão sobre a relação custo-efetividade da arquitetura quanto ao uso de recursos de nuvem deve ser realizada de forma centralizada para melhor explorar as oportunidades de otimização e permitir que as equipes de engenharia se concentrem nas soluções de aplicação.

a otimização de descontos oriundos do uso comprometido de recursos de nuvem deve ser gerenciada de forma centralizada para melhor aproveitar economias de escala e permitir que as equipes de engenharia mantenham o foco no uso otimizado dos recursos. 

os relatórios de gastos com serviços de nuvem sejam restritos à administração central, que pode definir e guiar os ajustes necessários, evitando sobrecarregar as equipes operacionais e de engenharia, as quais podem se concentrar nos aspectos de DevOps.

o orçamento de cada equipe de DevOps seja definido de forma centralizada, incluindo a atribuição de rubricas de recursos financeiros para gasto com tecnologias específicas, com o objetivo de otimizar globalmente o uso dos recursos na nuvem.

Apenas as camadas de Aplicação e Dados.

Apenas as camadas de Middleware e Sistema de Tempo de Execução. 

Apenas as camadas de Virtualização e Servidores. 

Apenas as camadas de Aplicação, Dados e Sistema de Tempo de Execução.

hardware (bare metal) de processamento e dispositivos de armazenamento instalados e administrados na infraestrutura de um provedor e que podem ser alocados aos clientes por meio de contratos de prestação de serviço.

sistemas de suporte ao desenvolvimento e operação de aplicações, os quais são hospedados na infraestrutura de um provedor e podem ser utilizados como serviço pelos clientes, sendo que o faturamento é realizado com base na quantidade de uso.

contêineres, máquinas virtuais e recursos de armazenamento, alocados elasticamente aos clientes por meio de APIs de serviço que permitem o faturamento com base no tipo de recurso e no tempo de alocação.

máquinas virtuais e capacidade de armazenamento, que podem ser escalados de forma elástica para atender a demanda dinâmica das aplicações, podendo sua alocação aos clientes ser gerenciada automaticamente por meio de APIs de serviços Web.

CI encorajar o uso de repositórios distintos para evitar interferência entre as diferentes tarefas de desenvolvimento em um projeto, com integração frequente dos repositórios e uso de testagem automática para garantir a ausência de erros, enquanto CD requer o empacotamento e deployment automáticos para reduzir o impacto de mudanças. 

CI envolver o uso de um repositório compartilhado, com automação de build e testagem a cada commit, enquanto CD envolve o empacotamento automático de cada build bem-sucedida, gerando uma nova release e deixando-a pronta para implantação (deployment) nos diferentes ambientes de produção.

CI requerer a realização contínua e automática de testes de integração para garantir que mudanças no código-fonte realizadas nos diferentes ramos (branches) do repositório não comprometam o comportamento correto dos componentes do sistema, enquanto CD envolve a implantação em ambiente de produção para a realização de testes em ambiente real.

CI determinar o emprego de testes unitários automáticos, eliminando a necessidade de testes manuais e garantindo que o comportamento do sistema permaneça correto após cada mudança, enquanto CD implica a realização automática de testes de integração após cada build e o subsequente empacotamento para deployment.

O branch new-feature é inicializado em um novo repositório, para o qual o conteúdo do repositório original é copiado e ao qual é adicionada a nova versão do arquivo oldfile.c, bem como o arquivo newfile.c. 

O branch new-feature é selecionado e preparado para commit, o qual ocorre subsequentemente, criando uma nova versão, que contém o arquivo oldfile.c modificado, assim como o novo arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e definido com espaço de trabalho, o qual contém a nova versão do arquivo oldfile.c, mas não o arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e nele é criada uma nova versão, a qual contém o arquivo modificado oldfile.c, assim como o novo arquivo newfile.c. 

reduzir a necessidade de idas e vindas ao banco de dados pela aplicação, sendo que stored procedures podem realizar controle de transações, enquanto stored functions podem ser chamadas dentro de consultas (queries) SQL.

alocar a lógica de negócio no próprio banco de dados, sendo que tanto stored procedures quanto stored functions podem ser chamadas dentro de consultas (queries) SQL realizadas pelas aplicações.

realizar processamento centrado nos dados dentro do próprio gerenciador de banco de dados, com a possibilidade de fazer commit ou rollback de transações no caso de stored functions.

melhorar o desempenho por meio da realização de processamento dentro do próprio banco de dados e do controle fino de transações, tanto em stored procedures quanto em stored functions.

Implementar as regras de domínio de negócio com Angular para facilitar sua adaptação a diferentes clientes, enquanto o back-end, implementado com Spring Boot, deve se limitar a operações CRUD e acesso ao banco de dados, de modo a facilitar a evolução da aplicação. 

Implementar as regras de negócio no back-end com Spring Boot para garantir segurança e reutilização por múltiplos clientes, enquanto a lógica de apresentação e de controle da interface de usuário deve ser implementada com Angular para garantir a interatividade da aplicação. 

Implementar as regras de validação e controle de acesso no front-end com Angular, pois a separação entre cliente e servidor já garante a consistência e segurança dos dados, enquanto o back-end, baseado em Spring Boot deve expor a lógica da aplicação por meio de APIs REST padronizadas.

Implementar o acesso aos dados no front-end com Angular, de modo que validações de dados específicas de usuário possam ser feitas sem gerar sobrecarga no servidor e que a lógica de negócio, implementada no back-end com Spring Boot possa ser independente do esquema do banco de dados.