os serviços individuais podem ser liberados como artefatos que podem ser implantados independentemente, sem exigir reconstrução ou rollout sincronizado do sistema completo.

o alinhamento de versões entre microsserviços garante que suas releases ocorram simultaneamente, evitando incompatibilidades entre componentes.

a arquitetura impõe uma estratégia fixa de rollout que padroniza a implantação em todos os ambientes onde o sistema deve ser implantado.

o pipeline de implantação compartilhado garante que todos os microsserviços passem pelos mesmos estágios de release ao mesmo tempo.

implementar a lógica de negócio, delimitar transações e compor a interface de usuário da aplicação.

representar entidades de negócio, coordenar objetos de domínio e formatar as respostas de requisições aos serviços da aplicação.

converter requisições de serviço em consultas ao banco de dados, definir o relacionamento entre objetos de domínio e coordenar a execução dos serviços.

tratar requisições HTTP, fazer o parsing dos parâmetros de entrada e delegar lógica de negócio para os serviços da aplicação.

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. 

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.

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.

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.

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.