Sistemas monolíticos
Normalmente o sistema monolíticos são aplicações tradicionais, onde tudo fica dentro do mesmo sistema. A forma mais fácil de distinguir se um sistema é monolítico é se quando queremos subir uma alteração no sistema de pagamentos, a parte de login precisa fazer o deploy junto.
A polemica por trás
Como os monolitos são mais velhos tem muitas polemicas relacionadas a eles, muitas pessoas falam de ser algo ultrapassado, que não escala, e que tem alto acoplamento. Porem muitos desses argumentos são falsos, por exemplo o stack overflow até hoje é um sistema monolítico. Outro ponto é que o sistema não fica altamente acoplado por conta própria, porem de fato acaba sendo "mais fácil" deixa ele altamente acoplado por conta do código estar ali já no mesmo sistema
Quando pode ser uma boa utilizar
- Novos projetos onde o modelo de negócio não está claro
- Instabilidade no core do negócio
- Evitar complexidade no deploy
- Evitar complexidade na operação
Tem esse artigo do Martin Fowler onde ele descreve o porque ele prefere aplicações que foram monolitos primeiro.
Ele fala sobre como na maioria das vezes nas quais ele viu aplicações que começaram como microsserviços os devs tiveram problemas no futuro porem quando começaram como monolitos e quando ficou muito grande quebraram em microsserviços geralmente gerou resultados positivos. Isso não se aplica para todos os casos principalmente quando as regras de negócios estão bem definidas e é uma aplicação que precisa de uma grande disponibilidade
Tipos de sistemas monolíticos
O livro Monolitos para microserviços lista os tipos de sistemas monolitos como 3 tipos
- Monolitos distribuídos
Black box
Single process
sendo que o single process pode ser dividido em 3 outros tipos
Alto acoplamento
Modular
Modular com bancos de dados segregados
Sistemas monolíticos acoplados
Pensando em longo prazo com uma entidade de "User" nós vamos precisar acoplar a ele:
- Dados Pessoais
- Endereços
- Cartões de crédito
- Tickets de suporte
- Compras
- Carrinho abandonado
- Devoluções
- Financiamento
- Indicações
- Reclamações
- E-mail mkt
- Campanhas
- Favoritos
- Lista de casamento
- Histórico de login
- Lista de preferencia de emails
- Avaliação de produtos
- Cartão de pontos
Essa entidade vai crescendo cada vez mais até que um momento a única solução acaba sendo quebrar para microsserviços. Os principais problemas dessa abordagem são
- Não existe contexto
- Entidades se relacionam
- Não há divisão. Tudo faz parte de tudo.
- Efeitos colaterais indesejados
Sistemas monolíticos modulares
DDD é um ponto de partida
podemos ter um user para cada contexto inclusive dependendo do contexto ele deixa de ser um user e passa a ser um convidado ou beneficiário
Separando os contextos em módulos podemos evitar o alto acoplamento.
- Módulos são quebrados em 'Bounded contexts'e eles conversam através de contratos e facades ou seja um modulo não deve saber o que tem no outro modulo
- As entidades podem ser "duplicadas" tendo apenas os atributos necessários.
- Equipes especializadas por módulos
- Alta coesão: O que muda junto, permanece junto
Sistemas monolíticos modulares com bancos de dados segregados
A diferença desse tipo de sistema é que cada modulo pode ter o seu próprio banco de dados. Assim faz com que os desenvolvedores de cada modulo tenham mais liberdade para trabalhar nos seus módulos sem medo de quebrar os outros.
Porem o ponto negativo é que vamos ter muitos dados duplicados, e tem que ser garantido a integridade dessas informações duplicadas.
Top comments (0)