Como criar um sistema monolítico realmente modular

[@marcelosantana2367]

Ótimo conteúdo Wesley, se possivel numa proxima criar um projeto pequeno e pratico, usando todo esse conceito, parabéns.

[@brunodiedrich625]

Esse vídeo virou a chave, muito mais fácil de entender tudo com a tua didática, muito obrigado pelo vídeo!

[@pauloaraujo3516]

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!

[@AlmirRPS]

Wow! Cara! Uma sacada top de estrutura! E o legal que fica perfeito para avançar pra microservices! Muito bom mesmo Wesley, parabéns!

[@dieg0dgm]

Achei bastante coerente a abordagem, parabéns por compartilhar e pelo canal.

[@thiagovalls6125]

Muito top a abordagem Wesley... Acho que faz muuuuuito sentido e faz com que sejamos profissionais até mesmo ao criar monolitos. PARABÉNS!!!

[@acidineydias]

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.

[@alquimistavoador]

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.

[@gustavotrr6698]

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.

[@ricardospara]

Parabéns pelo conteúdo Wesley. Muito bom!

[@JoaoPauloPVillela]

Show, gostei muito, e iria me ajudar muito em um projeto que estou trabalhando.

[@putzz67767]

Muito bom o vídeo! Parabéns!

[@ederelfs]

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.

[@paulosoares2965]

Como sempre, ótimo conteúdo... parabéns!

[@dayaneoliveiralopes4091]

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!

[@marckvaldowallas4331]

Cara muito bom esse conteudo... Deveria trazer mais conteudo de monolitico....

[@danielneto6619]

Seria muito interessante ver isso na prática com algum framework "comercial", como o Laravel.

[@dayaner.1096]

Ótimo video, obrigada por todo o ensinamento!

[@luscasleo]

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.

[@williambrito469]

Perfeito! Vou conseguir melhorar muito meu monolito.

[@stifl0w]

Muito bom Wesley!

[@rafauell]

Que aula, parabéns

[@celsopires1999]

Parabéns pela abordagem, Wesley. Na minha opinião, as tabelas do produto deveriam ser diferentes por contexto, usando evidentemente o mesmo ID.

[@AtilaDelcanton]

Ó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!

[@antoniothomacelli]

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.

[@jeanjagnow2524]

Ó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.

[@sauloalmeidadev]

Ótimo vídeo, estou pensando em fazer um projeto em .NET aplicando essa abordagem para estudo, abraço!

[@diegoclairr]

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.

[@noriller]

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.

[@putzz67767]

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?

[@UzmakiThiagoSantAnna]

Uma ótima abordarem, só fiquei na dúvida de como eu modularia a classe de entidade. Mas isso é o desafio. Obrigado.

[@daniel_goncalves]

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

[@acidineydias]

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!!!

[@Nilander]

excelente

[@danielvinicius4906]

Dei o like, boiei na parte de inversão de controle e interfaces como eu vou comunicar isso internamente?

[@elsofernandes]

muito bom

[@ProSimples]

Ola pessoal, onde eu vejo o link dos cursos de voces? Nao acho em lugar nenhum.

[@valmirknasel]

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.

[@fbrunof]

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.

[@MrRodrigorrch]

Tem exemplo no github ?!

[@patrickbarboza7575]

Me surgiu uma duvida. Criando diversas classes de Produto, essas classes não teriam grandes chances de serem anêmicas?

[@VanNeves]

Tu tá no Mac usando o Microsoft Edge? Nunca tinha visto isso na minha vida!