Como criar um sistema monolítico realmente modular
Vložit
- čas přidán 25. 08. 2024
- Nesse vídeo você terá a visão de como criar um sistema monolítico realmente modular e que seja facilmente migrado para microsserviços quando fizer sentido.
👇🏼 Participe da Imersão Full Stack && Full Cycle:
Acesse: imersao.fullcy...
Garanta gratuitamente sua vaga no evento que vai mudar sua carreira completamente.
E não esquece de deixar seu 👍 nos vídeos. Isso nos ajuda a saber se você tá curtindo, beleza?
→ Siga-nos no Instagram: @devfullcycle
→ Participe de nosso Canal no Telegram:
t.me/devfullcycle - Zábava
Ótimo conteúdo Wesley, se possivel numa proxima criar um projeto pequeno e pratico, usando todo esse conceito, parabéns.
Realmente, eu desenvolvi um sistema recente no modelo que você mostrou no início, mas já vi onde pode gargalar e quais pontos devo me preocupar com o crescimento do sistema.
Para quem está estudando DDD, como eu estou, esse conteúdo é extremamente útil.
Deu uma boa clareada na ideia de como aplicar bounded contexts de forma clara e simples. Conteúdo muito bom Wesley!
Wow! Cara! Uma sacada top de estrutura! E o legal que fica perfeito para avançar pra microservices! Muito bom mesmo Wesley, parabéns!
Esse vídeo virou a chave, muito mais fácil de entender tudo com a tua didática, muito obrigado pelo vídeo!
Wesley, Esse teu conteúdo caiu como uma luva. Ontem mesmo, estava com uns colegas na empresa a fazer brainstorm sobre isso... e a medida que descutiamos ... Acabei por chegar a mesma conclusão. Que se for fazer um monolitico modular as "models" não devem ser compartilhadas e sim, trabalhadas por contexto.
Muito obrigado pela clareza, com certeza irei explorar mais esse modelo.
Seria muito interessante ver isso na prática com algum framework "comercial", como o Laravel.
Gostei muito da aula, eu nunca tinha pensado dessa forma. Sem dúvidas separar por contexto parece ser uma abordagem mto poderosa.
Só fiquei com um puga atrás da orelha sobre como um orm vai funcionar nesse contexto, ainda não consegui enxergar isso de forma clara. Preciso por a mão na massa pra ver as dificuldades acontecendo e então tentar conciliar tudo.
Deixo aq inclusive uma sugestão de vídeo, uma continuação dessa aula mostrando na prática como fazer esta separação por contexto.
Muito top a abordagem Wesley... Acho que faz muuuuuito sentido e faz com que sejamos profissionais até mesmo ao criar monolitos. PARABÉNS!!!
Achei bastante coerente a abordagem, parabéns por compartilhar e pelo canal.
Perfeito Wesley! Excelente!
Uma outra coisa que eu também já fiz foi "prever" uma comunicação entre microsserviços, criando classes para intermediar a comunicação entre módulos, como de um lado "vendasClient*Service" e do outro "suporteController*Service" e permitindo que elas se comunicassem enviando um DTO de um para o outro. Quando separar em serviços fica muito fácil desacoplar essa comunicação.
Que vídeo bacana, depois que comprei o curso fullcycle expandi bastante minha mente e fico feliz em saber que eu e meu esposo estamos fazendo um Monolito nessa idéia que foi abordado. Gratidão Wesley por todos ensinamentos!
Parabéns pelo conteúdo Wesley. Muito bom!
Parabéns pelo vídeo Wesley, muito esclarecedor.
Quem sabe num futuro próximo dê pra fazer esse mesmo exemplo de uma forma mais prática, codando mesmo.
Obrigado por compartilhar.
Muito bom o vídeo! Parabéns!
Parabéns pela abordagem, Wesley. Na minha opinião, as tabelas do produto deveriam ser diferentes por contexto, usando evidentemente o mesmo ID.
Parabéns pelo vídeo. Acho ele muito necessário nesse momento de transição no formato em que funcionam os ecossistemas de aplicações monoliticas para sistemas distribuídos, uma vez que, apesar da notável diferença e vantagem na migração de um pro outro, eu - no caso - ainda não tenho todo o domínio ou opinião formada em cima do formato anterior o que me ajudaria a tomar decisões mais assertivas na concepção e desenvolvimento de projetos.
Cara muito bom esse conteudo... Deveria trazer mais conteudo de monolitico....
Perfeito! Vou conseguir melhorar muito meu monolito.
Como sempre, ótimo conteúdo... parabéns!
Show, gostei muito, e iria me ajudar muito em um projeto que estou trabalhando.
Que aula, parabéns
Muito bom Wesley!
Ótimo video, obrigada por todo o ensinamento!
Ótimo conteúdo como sempre, se puder ter uma com um pequeno exemplo prático ajudaria muita a assimilar melhor... mas de qualquer modo perfeita a explicação!
Muito bom o vídeo Wesley, parabéns!
Se conseguir, faz um vídeo sobre dockertest com go. Parece bem interessante e está sem conteúdo de qualidade como você faz.
Valeu, acho que desde comecei a estudar, só tenho pego temas de Micro-Serviço. Ruim que isso faz vc sempre pensar nessa estrutura, mesmo para projetos pequenos.
Ótimo vídeo, estou pensando em fazer um projeto em .NET aplicando essa abordagem para estudo, abraço!
Ótimo vídeo, estou a um tempo desenvolvimento um sistema monólito modular com. Net core, no meu caso possuí um host onde conecto os módulos, e tem o core onde fica as classes bases e coisas referentes ao sistema como menus e configurações de usuários e sessões gerenciadas por banco, uma pasta chamada modules onde crio as pastas por exemplo Company com uma Razor class library para as controllers e Views, APIs, application com os commands e regras de negócio, domain, infrastructure.
Achei massa a abordagem. Mas acho que poderia ter exemplos aplicado. Criar umas classes no spring boot e vai mostrando isso aí que vc escreveu. Pra ficar mais claro
Acho que a abordagem que ele usou foi melhor, não associar a ferramentas ... Se não seria um conteúdo bem nichado ( Por exemplo, eu entendo tanto de Spring e Java quanto entendo de Russo... Nada ) ... Mas, aí poderias criar um repo, com um exemplo e partilhar com a galera... ^^
Show!!!
excelente
Muito bom. Falta conteúdo nacional que trate de arquitetura. O seu canal é um grande refresco.
Sobre a separação de contextos, o que vc pensa sobre a "arquitetura vertical", que separa as "features" verticalmente e diminui a necessidade de algumas dessas abstrações, como repositórios?
Uma ótima abordarem, só fiquei na dúvida de como eu modularia a classe de entidade. Mas isso é o desafio. Obrigado.
Algo que eu fiz aqui foi realmente separar pelos dominios (tava usando Nestjs)
Então cada dominio: vendas, atendimento, marketplace cada um tinha controller, services, infra próprios dentro da mesma pasta (e quando necessário sub dominios... a mesma coisa)
Fica fácil de controlar a aplicação, porque cada domínio tinha suas próprias coisas tudo dentro dela mesma
to num projeto novo onde ta tudo separado em controller, services... mesmo com subpastas você precisa ficar pulando de um lado pro outro e torcer pra não entrar num arquivo errado por engano.
muito bom
Dei o like, boiei na parte de inversão de controle e interfaces como eu vou comunicar isso internamente?
Parabéns pelo vídeo! Aos 26:41, não seria o caso de usar o padrão DTO para criar várias representações distintas para a mesma informação que está no banco, no caso para o produto? O produto seria um monstro no banco, mas com o uso do DTO, podemos criar AtendimentoProdutoDTO; SuporteProdutoDTO; CheckoutProdutoDTO; MktplaceProdutoDTO; FaturamentoProdutoDTO, cada um carregando apenas os dados referentes ao seu respectivo contexto e todos poderiam ainda estender uma interface ProdutoDTO que poderia conter os dados mínimos que caracterizam um produto. Pelo menos foi assim que entendi a implementação do padrão DTO: você cria diversas representações diferentes do mesmo objeto, dependendo do contexto que ele está inserido e por mais que a tabela produto seja gigante no banco, só irão ser carregadas as informações inerentes ao respectivo contexto que fez a chamada. Inclusive esse tipo de adaptação, a gente pode usar pra construir novos módulos sem ter que alterar a estrutura da base de dados, isso pra um sistema monolítico. Pro caso de microserviços, já teria que quebrar em vários bancos e trabalhar com a consistência eventual dos dados.
Pelo que entendo a utilização dos DTO's servem apenas para entrada e saída de dados na aplicação. Nesse caso específico ele quis tratar as situações em que mudanças no domínio precisam ser feitas durante novas implementações/correções, o uso do DTO não eliminaria essa necessidade. Um exemplo disso é por exemplo precisar incluir uma coluna nova.
Ola pessoal, onde eu vejo o link dos cursos de voces? Nao acho em lugar nenhum.
Tem exemplo no github ?!
Me surgiu uma duvida. Criando diversas classes de Produto, essas classes não teriam grandes chances de serem anêmicas?
Tu tá no Mac usando o Microsoft Edge? Nunca tinha visto isso na minha vida!