Parabéns pelo artigo e obrigado por compartilhar sua visão e experiência. Poderia endossar praticamente tudo que você mencionou neste artigo.
Eu somente gosto de trazer a tona uma deficiência da comunidade como um todo que diz respeito a conceitos. Estas propostas de arquiteturas de aplicação citadas estão repletas de conceitos, normalmente abordagens para problemas conhecidos.
Muitas delas não lhe dizem como você deve exatamente implementar, apenas mencionam que determinadas preocupações precisam ser tratadas.
Vou citar um exemplo muito simples, apesar de ser mais relevante pra quem usa java creio que qualquer desenvolvedor de outra linguagem vai entender o objetivo.
Imagine que existe uma regra de negócio que o CPF deve estar válido (isso pode ser tratado como regra de formatação ou algo assim, mas tem o famoso mod11 e tal). Uma outra regra para o nome ter entre 3 e 100 caracteres, e outra regra de que a data de nascimento deve estar obrigatoriamente no passado. Como se tratam de regras de domínio de negócio a sugestão é que estas sejam tratadas nas classes de domínio. Pois bem, se usar Beans Validation do java, três anotações em atributos de uma classe de domínio ou DTO resolvem isso. Se no controller vc adicionar uma anotação @Valid o framework vai invocar estas regras bem antes de processar o controller ou service/entidades. Ai fica a questão: É válido chamar uma regra de domínio na camada do controller?
Entendo que isso esteja bem alinhado com o que muitos de nós já enfrentamos. Todos querem fazer sistemas à prova de tudo e perdemos tempo e dinheiro protegendo e preparando a aplicação para um cenário que simplesmente não existe. Creio que você foi muito feliz ao não atacar a metodologia mas sim a implementação. Muitos dos princípios que você adotou são usados pelas sugestões de arquitetura, apenas muda a nomenclatura mas os princípios são os mesmos.
Como sempre, o bom senso deve prevalecer e só nos alinharmos a uma arquitetura mais complexa quando precisarmos lidar com problemas e cenários mais complexos.
Tenho um exemplo que gosto de citar sobre um sistema monolitico com um banco H2 que suportou o fluxo de uma transpordora por um mês inteiro depois que uma versão mais moderna não parava de pé por consumir mais recursos e trabalhar distribuida num ambiente com uma infraestrutura de rede instável.
Software Engineer - Backend | Cloud
I write about software engineering, career, and distributed systems.
In my spare time, I play video games and D&D.
Opinions are my own.
Opa Marcelo, obrigado pelo comentário. Gostei bastante do seu exemplo com o Beans Validation.
Sendo bem honesto, eu talvez sendo o paranóico que eu sou, implementaria a validação no controller (fail-fast) e DE NOVO no domínio (entidades consistentes).
Você está certo, o foco do post foi mais mostrar como eu vi sistemas sendo feitos e demonstrar como isso quebraria outras arquiteturas mas mesmo assim os sistemas funcionam e são bem testados/etc...
A única parte que eu discordo levemente de você é essa aqui:
Muitas delas não lhe dizem como você deve exatamente implementar, apenas mencionam que determinadas preocupações precisam ser tratadas.
No caso da Clean especificamente. No livro que descreve a Clean o autor é BEM prescritivo e deixa claro como deve ser implementada. Somos obrigados a segui-lo cegamente? Não. Mas aí a nossa arquitetura é mais uma clean-hugo ou clean-marcelo do que a clean-architecture (e tudo bem ser assim, tá?).
Se curtiu dá uma olhada nos outros posts, seu comentário me agregou bastante. Obrigadão!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Parabéns pelo artigo e obrigado por compartilhar sua visão e experiência. Poderia endossar praticamente tudo que você mencionou neste artigo.
Eu somente gosto de trazer a tona uma deficiência da comunidade como um todo que diz respeito a conceitos. Estas propostas de arquiteturas de aplicação citadas estão repletas de conceitos, normalmente abordagens para problemas conhecidos.
Muitas delas não lhe dizem como você deve exatamente implementar, apenas mencionam que determinadas preocupações precisam ser tratadas.
Vou citar um exemplo muito simples, apesar de ser mais relevante pra quem usa java creio que qualquer desenvolvedor de outra linguagem vai entender o objetivo.
Imagine que existe uma regra de negócio que o CPF deve estar válido (isso pode ser tratado como regra de formatação ou algo assim, mas tem o famoso mod11 e tal). Uma outra regra para o nome ter entre 3 e 100 caracteres, e outra regra de que a data de nascimento deve estar obrigatoriamente no passado. Como se tratam de regras de domínio de negócio a sugestão é que estas sejam tratadas nas classes de domínio. Pois bem, se usar Beans Validation do java, três anotações em atributos de uma classe de domínio ou DTO resolvem isso. Se no controller vc adicionar uma anotação @Valid o framework vai invocar estas regras bem antes de processar o controller ou service/entidades. Ai fica a questão: É válido chamar uma regra de domínio na camada do controller?
Entendo que isso esteja bem alinhado com o que muitos de nós já enfrentamos. Todos querem fazer sistemas à prova de tudo e perdemos tempo e dinheiro protegendo e preparando a aplicação para um cenário que simplesmente não existe. Creio que você foi muito feliz ao não atacar a metodologia mas sim a implementação. Muitos dos princípios que você adotou são usados pelas sugestões de arquitetura, apenas muda a nomenclatura mas os princípios são os mesmos.
Como sempre, o bom senso deve prevalecer e só nos alinharmos a uma arquitetura mais complexa quando precisarmos lidar com problemas e cenários mais complexos.
Tenho um exemplo que gosto de citar sobre um sistema monolitico com um banco H2 que suportou o fluxo de uma transpordora por um mês inteiro depois que uma versão mais moderna não parava de pé por consumir mais recursos e trabalhar distribuida num ambiente com uma infraestrutura de rede instável.
Opa Marcelo, obrigado pelo comentário. Gostei bastante do seu exemplo com o Beans Validation.
Sendo bem honesto, eu talvez sendo o paranóico que eu sou, implementaria a validação no controller (fail-fast) e DE NOVO no domínio (entidades consistentes).
Você está certo, o foco do post foi mais mostrar como eu vi sistemas sendo feitos e demonstrar como isso quebraria outras arquiteturas mas mesmo assim os sistemas funcionam e são bem testados/etc...
A única parte que eu discordo levemente de você é essa aqui:
No caso da Clean especificamente. No livro que descreve a Clean o autor é BEM prescritivo e deixa claro como deve ser implementada. Somos obrigados a segui-lo cegamente? Não. Mas aí a nossa arquitetura é mais uma clean-hugo ou clean-marcelo do que a clean-architecture (e tudo bem ser assim, tá?).
Se curtiu dá uma olhada nos outros posts, seu comentário me agregou bastante. Obrigadão!