Executando verificação de segurança...
Em resposta a [Não disponível]
2
ThiagoCoppi

Gosto da abordagem de primeiramente a criação de um monolito bem escrito com domínios bem dividos, principalmente quando é um software que a ideia do produto está sendo criada juntamente com a codificação. Acho que pensar em uma divisão estrutural do projeto em microserviços seja muito complexa devido a ideia do negócio ainda estar sendo construída.

Trabalhei em um projeto de uma instituição bancária que tinha por volta de uns 20 desenvolvedores no mesmo projeto, um monolito, e éramos dividídos em várias squads cada uma com o seu "papel", no final sempre tínhamos problemas com as entregas, como muito merge, conflito etc...

Creio que se já tivessemos a concepção de divisão em microserviços com equipes grandes acho muito válido, pois cada um mexe no seu domínio e caso necessário solicita para a squad responsável pelo microserviço a mudança necessária.

No fio do bigode, acho que para QUASE toda a empresa em questão de performance um monolito será o suficiente, porém vejo microserviços muito mais além do que performance, como foi o caso que citei acima.

Carregando publicação patrocinada...
1
1
MigMoroni

Acredito muito neste quesito, do monolito ser o modelo ideal a projetos em seu inicio (fora excessões), principalmente MVPs.

Em meu caso, um exemplo de framework que gosto de dar, é o Ruby On Rails, que vem nesse sentido em permitir montar um monolito bem estruturado de forma rápida. É muito usado pelas startups para colocar um mvp para rodar rápido.

Todavia, como este pode ser mais lento que outras soluções em C#, Java e Elixir, a depender da necessidade de performance do projeto, é feito um processo de substituição.
Isto permite enfim, desenvolver com mais calma o backend, com fases de uso de uma tecnologia mais simples primeiro, para enquanto isso, dedicar mais tempo para a mais complexa.