Muito legal, acabei de me inscrever para o desafio. Escrevi os primeiros testes de unidade do código da empresa e por um bom tempo fui o único a faze-los. Ainda não consegui convencer a gestão da importância dessa etapa, então, bora estudar para fazer testes melhores e pelo menos convencer os outros desenvolvedores que forem dar manutenção nos meus códigos 💪🏾
Balta, levando em consideração DDD e clean arquitecture, devo centralizar um serviço na camada de domínio, ou apenas a interface no domínio e a classe concreta na aplicação (particularmente acho melhor). Pergunto isso, pois já vi muitas vezes serviço todo no domínio
No domínio ficam as interfaces as implementações ficam na camada de Infra... agora em relação a Domain Service, eles são implementados no domínio (Afinal, são domain services) e quaisquer dependências que eles venham a ter (Que dependa de algo externo como repositórios) são implementadas na infra, definidas no domínio e injetadas nos domain services... Vou mostrar isso no próximo curso!
Olá, pessoal. Fiquei com uma dúvida: Você fez algumas validações diretamente no código dos métodos. Mas como ficariam as "validations" (com FluentValidation, por exemplo) nesse cenário? O que eu deveria "checar" no método e o que eu deveria deixar para a validação? Ou "validações" não têm relação com "testes de domínio"? Valeu!
Eu sempre consegui aplicar essa abordagem de Entidade Rica + Testes quando trabalhando com Code-First para geração do banco através das entidades. Dessa maneira, as propriedades da entidade são mapeadas em colunas da tabela e os métodos aplicam as regras de negócio na entidade. Minha dúvida é como conseguir fazer uma entidade ser rica quando estamos trabalhando com Database-First e as classes geradas são anêmicas e auto-geradas, o que impossibilita editar elas? Uma abordagem que vi foi criar uma classe CustomerDomain só que nesse caso essa classe ficava a cargo de aplicar regras de negócio, buscar dados do banco (carregando, assim, as entidades anêmicas), salvar dados no banco, etc. Essa abordagem me soa muito errada
Não tem como! É uma outra abordagem... chamada de Data-Driven... Você pode ter testes de unidade, inclusive usar arquitetura limpa, mas é uma outra abordagem!
🎃 PARTICIPE DO DESAFIO CAÇA AOS BUGS => go.balta.io/desafio-caca-aos-bugs?
Muito legal, acabei de me inscrever para o desafio. Escrevi os primeiros testes de unidade do código da empresa e por um bom tempo fui o único a faze-los. Ainda não consegui convencer a gestão da importância dessa etapa, então, bora estudar para fazer testes melhores e pelo menos convencer os outros desenvolvedores que forem dar manutenção nos meus códigos 💪🏾
Pra cima 🚀
Bem interessante! Ansioso para quando abordar moq
Boaaa!!! PRa cima!!!
Balta, levando em consideração DDD e clean arquitecture, devo centralizar um serviço na camada de domínio, ou apenas a interface no domínio e a classe concreta na aplicação (particularmente acho melhor). Pergunto isso, pois já vi muitas vezes serviço todo no domínio
No domínio ficam as interfaces as implementações ficam na camada de Infra... agora em relação a Domain Service, eles são implementados no domínio (Afinal, são domain services) e quaisquer dependências que eles venham a ter (Que dependa de algo externo como repositórios) são implementadas na infra, definidas no domínio e injetadas nos domain services...
Vou mostrar isso no próximo curso!
Olá, pessoal. Fiquei com uma dúvida: Você fez algumas validações diretamente no código dos métodos. Mas como ficariam as "validations" (com FluentValidation, por exemplo) nesse cenário?
O que eu deveria "checar" no método e o que eu deveria deixar para a validação? Ou "validações" não têm relação com "testes de domínio"?
Valeu!
Sim, você pode checar na própria entidade... um bom exemplo disso é o Flunt com uso dos Domain Notifications:
www.nuget.org/packages/Flunt
Eu sempre consegui aplicar essa abordagem de Entidade Rica + Testes quando trabalhando com Code-First para geração do banco através das entidades. Dessa maneira, as propriedades da entidade são mapeadas em colunas da tabela e os métodos aplicam as regras de negócio na entidade.
Minha dúvida é como conseguir fazer uma entidade ser rica quando estamos trabalhando com Database-First e as classes geradas são anêmicas e auto-geradas, o que impossibilita editar elas?
Uma abordagem que vi foi criar uma classe CustomerDomain só que nesse caso essa classe ficava a cargo de aplicar regras de negócio, buscar dados do banco (carregando, assim, as entidades anêmicas), salvar dados no banco, etc. Essa abordagem me soa muito errada
Não tem como! É uma outra abordagem... chamada de Data-Driven... Você pode ter testes de unidade, inclusive usar arquitetura limpa, mas é uma outra abordagem!
Top demais!
🚀