Questões de Engenharia de Software - Ciclo de Vida de Software

ScaleTransition.

Placeholder.

PageStorage.

Banner.

FutureWidget.

Determina o uso de bancos de dados NoSQL em substituição aos tradicionais bancos de dados relacionais.

Propõe que os diversos microsserviços que compõem uma aplicação sejam executados na mesma máquina, virtual ou real, onde o servidor de banco de dados que atende a essa aplicação é executado.

Determina que microsserviços devem usar arquivos XML e JSON para persistência de dados, sem utilizar servidores de bancos de dados relacionais ou NoSQL.

Propõe que microsserviços sejam implementados por meio de stored procedures dentro de servidores de bancos de dados relacionais, e não em linguagens convencionais (Java, Python etc.).

Promove gerenciamento de dados descentralizado, propondo que cada microsserviço tenha seu próprio banco de dados, sem que um acesse o banco de dados do outro.

Nomes de classes declaradas em um círculo externo podem ser referenciados pelo código em um círculo interno, desde que esse código no círculo interno corresponda a declarações e implementações de subclasses daquelas declaradas no círculo externo.

O nome de algo declarado em um círculo interno não deve ser referenciado pelo código em um círculo externo.

O nome de algo declarado em um círculo externo deve, ao menos uma vez, ser referenciado pelo código em um círculo interno.

O nome de algo declarado em um círculo externo não deve ser referenciado pelo código em um círculo interno.

As dependências de código-fonte devem apontar na direção dos mecanismos, partindo das políticas, ou seja, políticas dependem dos mecanismos.

são consideradas sistemas legados e, portanto, devem ser migradas para arquitetura de microsserviços assim que possível.

podem ser construídas de forma modular, mas tipicamente apresentam limitações de escalabilidade para alta demanda.

podem utilizar bancos de dados relacionais, mas não bancos de dados NoSQL.

precisam ser desenvolvidas em linguagens compiladas, uma vez que precisam ser distribuídas na forma de um único arquivo executável.

podem ser escaladas horizontalmente para atender a demanda, mas não verticalmente.

se recomenda não inserir scripts e arquivos de configuração relacionados à criação automática de infraestrutura em repositórios de sistemas de controle de versão, por razões de segurança, uma vez que segredos e detalhes sobre a infraestrutura ficariam mais expostos.

é justificada exclusivamente quando a equipe trabalha de forma geograficamente distribuída, uma vez que, estando no mesmo escritório físico, haveria maior facilidade em trabalhar com pastas compartilhadas em um servidor local, o que provê maior simplicidade de uso.

é recomendada para equipes grandes, mas pouco recomendada para equipes pequenas, sendo que, em projetos realizados por um único desenvolvedor, essa prática não deve ser adotada.

se justifica utilizar vários repositórios e sistemas de versionamento, simultaneamente, para diferentes tipos de arquivos, artefatos de projeto, objetos e serviços, mesmo que isso requeira conhecimentos da equipe em diferentes ferramentas.

sua utilização se dá exclusivamente pela equipe de desenvolvimento, e não pela equipe de operações, já que esta equipe não lida com código-fonte, arquivos de scripts de testes automatizados etc.