DEV Community

Cover image for Design: Monolitos Modulares - Parte 3

Design: Monolitos Modulares - Parte 3

William Santos on May 08, 2023

Olá! Este post é uma sequência de Design: Monolitos Modulares - Parte 2, e nele demonstraremos os conceitos abordados no post anterior a partir do...
Collapse
 
wmscode profile image
Willian Menezes

Opa mestre! Otimo conteudo...

Tenho uma duvida, na controler voce tomou algumas decisoes para definir se eh uma ordem de compra ou venda.

Essa implementacao nao da muita responsabilidade para a controller? O Ideal nao seria ter um manipulador para gerir esse fluxo da aplicacao, deixando assim a controller apenas como um ponto de entrada e saida?

Abracos, seus artigos sao otimos...

Collapse
 
wsantosdev profile image
William Santos

Fala, xará!

Abordei a questão desta forma por simplicidade e, em boa parte dos casos é o suficiente, diga-se.
A ideia de utilizar Handlers (normalmente associados ao MediatR) acaba sendo um exagero em muitos casos porque um Controller bem implementado tende a ter poucos métodos e a não mudar com frequência.

Eu poderia ter implementado um Domain Service para injetar no Controller mas, pensa comigo: qual seria o ganho? Escrever mais código apenas pra fazer uma separação lógica numa aplicação simples faria sentido?

Essa é a pegadinha! Haha!

Muito obrigado pelo carinho de sempre. 💙

Collapse
 
wmscode profile image
Willian Menezes

Tudo vai da sensibilidade na hora de fazer o codigo entao?

Esse pensamento que voce colocou serviria tambem para aplicacoes maiores e corporativas.

Thread Thread
 
wsantosdev profile image
William Santos

Cada caso é um caso. A necessidade é quem vai ditar a complexidade técnica.

Manter-se simples vale pra toda e qualquer aplicação. O que vai variar é o momento em que aumentar a complexidade pode ser necessário.

No fim, design é sobre isso: organizar seus componentes da forma mais simples e viável possível.

Thread Thread
 
wmscode profile image
Willian Menezes

É isso... valeu pelas dicas, tamo junto!

Collapse
 
thiagochfc profile image
Thiago Christopher

Excelente conteúdo!

Você conseguiria abordar no futuro uma diferença clara entre evento de domínio e evento de integração e como ela se comportaria nessa aplicação? Acredito que seria um conteúdo incrível para sintetizar os conhecimentos.

Collapse
 
wsantosdev profile image
William Santos

Fala, Thiago. Tudo bom?
Muito obrigado pelo comentário.

Esta questão já está prevista para a minha série, que vai se chamar Modelagem de Domínios (ou algo do tipo. Haha!). A intenção é mostrar, do início ao fim, os aspectos de uma boa modelagem partindo do DDD.

Exemplificando a partir da demo deste post, e bem a grosso modo, o que posso dizer é que eventos de domínio são aqueles que afetam diretamente o estado de entidades dentro de um mesmo domínio (contexto delimitado / bounded context). Sua principal característica do ponto de vista da aplicação, é que são disparados e ouvidos no mesmo processo (em memória).

Já os eventos de integração são aqueles que tem por finalidade disponibilizar informações para outros contextos delimitados e, não raro, são aqueles que costumam ser propagados por meio de mensageria, fora do processo da aplicação (o que foi simulado na demo, por exemplo, quando uma Ordem é criada e a Exchange precisa ficar sabendo).

Ficou claro? Qualquer coisa, fica à vontade pra perguntar.

Valeu!

Collapse
 
thiagochfc profile image
Thiago Christopher

Opa, William Santos. Tudo sim e você?

Consegui compreender e fez sentido sim.

Aguardando essa sua nova série, é um assunto em particular que eu tenho muito interesse.

Mais uma dúvida, a Order possui alguns status que foram representados na própria classe mas não poderia ser do tipo Enum?

Thread Thread
 
wsantosdev profile image
William Santos

Fala, Thiago! Tudo em ordem por aqui.

Boa pergunta. E a resposta é: sim, mas melhor não.

Embora um enum seja uma opção viável, ele apresenta dois problemas:

  1. É preciso sempre se lembrar de usar o atributo Description, para que seu valor numérico não seja usado no método ToString.
  2. Não é possível adicionar propriedades e comportamentos a um enum. Assim sendo, caso algum dado complementar seja necessário ao OrderStatus, por exemplo, seria impossível adicionar.

Esta implementação é um pattern chamado enum type (ou enumeration classes), e você pode conferir mais detalhes no link abaixo:

lostechies.com/jimmybogard/2008/08...

Valeu! ✌🏾

Collapse
 
rafaelporto profile image
Rafael Monteiro Porto

Muito bom post, Will! Uma pergunta: o que você acha de mover os controllers da API para dentro dos módulos, mantendo todo o código concentrado? Desta forma o módulo poderia mais facilmente evoluir para um sistema deparado, caso necessário.

Collapse
 
wsantosdev profile image
William Santos

Fala, Rafa! Tudo bom?
Muito obrigado pela comentário, e é uma ótima pergunta!

Não incluir os Controllers nos módulos foi uma decisão arbitrária considerando flexibilidade. Ou seja, da forma como estão implementados, os módulos podem ser utilizados em qualquer tipo de aplicação (Web, Desktop, CLI etc).

Não é um problema incluir os Controllers nos módulos quando já está definido que a aplicação será exclusivamente Web. Entretanto, faço uma observação: é preciso ter cuidado na interação entre os módulos. Porque, se o Controller for utilizado como ponto de entrada no lugar de serviços, haverá acoplamento entre eles em situações onde um serviço de domínio seria necessário (como no envio de ordens do exemplo).

Portanto, é preciso conhecer bem os casos de uso para entender se essa abordagem faz sentido.

Valeu!

Collapse
 
wiliambuzatto profile image
Wiliam Buzatto

Boa!

Collapse
 
wsantosdev profile image
William Santos

Valeu, xará! ✌🏾💙