Discussão em Português [pt-br]

[ivanpaulovich]

Ainda que issues em inglês possam alcançar uma audiência maior e ter mais interaçoes, eu gostaria de encorajar os desenvolvedores em língua portuguesa a usarem este tópico para discussão.

Sejam bem vindos e vocês terão atencão especial.

Pinned issue for interacting with Brazilian-Portuguese developers community.
English Speakers, please unsubscribe 👀

[maikmb]

Gostaria de ajudar no projeto!

[ivanpaulovich]

Olá @maikmb,

O que o projeto mais precisa no momento é de uma interface de usuário (React, Blazor, etc). Se tiver interesse nisso seria bem vindo.
No mais, fazendo perguntas já está ajudando bastante.

[maikmb]

Eu posso tentar ajudar com uma interface em ReactJs. Seria para realizar as operações da API? Em seg, 20 de jan de 2020 09:54, Ivan Paulovich <notifications@github.com> escreveu:

…

Olá @maikmb <https://github.com/maikmb>, O que o projeto mais precisa no momento é de uma interface de usuário (React, Blazor, etc). Se tiver interesse nisso seria bem vindo. No mais, fazendo perguntas já está ajudando bastante. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/ivanpaulovich/clean-architecture-manga/issues/149?email_source=notifications&email_token=ABFQNIGLSXSULAROCFRHWNTQ6WNJVA5CNFSM4KJAKVZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJMQ6FQ#issuecomment-576261910>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFQNICROQZBHA5KOUKF7ZLQ6WNJVANCNFSM4KJAKVZQ> .

[ivanpaulovich]

Sim e seria muito bem vindo.

Coloquei no azure uma versao da API: https://clean-architecture-manga.azurewebsites.net/swagger/index.html e acho que preciso corrigir a URL de autenticacao que deveria ser https://clean-architecture-manga.azurewebsites.net/login.

[maikmb]

Combinado! Vou iniciar uma nova branch para incluirmos o projeto web.

[leandrofagundes]

Eu por enquanto fico gerando dúvidas na minha cabeça pra ver se gero uma na tua também hahaha.
@ivanpaulovich, eu não consigo vislumbrar a criação de classes que dependem de várias tabelas nesse modelo. Tipo um relatório e seus filtros.

1. Todos os filtros devem estar na DTO da Request pro caso de uso?
2. Digamos que eu vou apresentar uma lista de contas, mas quero mostrar o saldo dela, o nome do cliente e o nome do gerente. Minha busca vai ser no repositório de accounts, mas pra pegar o nome do gerente preciso ir em outro repositório. Em que momento faço essa mescla dos dados?

[ivanpaulovich]

Olá @leandrofagundes,

Todos os filtros devem estar na DTO da Request pro caso de uso?
Digamos que eu vou apresentar uma lista de contas, mas quero mostrar o saldo dela, o nome do
cliente e o nome do gerente. Minha busca vai ser no repositório de accounts, mas pra pegar o
nome do gerente preciso ir em outro repositório. Em que momento faço essa mescla dos dados?

1. Sim. Filtros na DTO do Request.
2. Você nao precisa reutilizar os repositorios para gerar o relatorio. Ao inves de usar os Repositorios você modela uma interface para consultas:

public interface IRelatorioContas
{
     Task<RelatorioContasModel> BuscarResumoContas(string nomeGerente, int UF);
}

E no seu caso de uso, você injeta IRelatorioContas, a implementacao você faz na Infrastruture e acessa diretamente o Context do EF ou SQL crú,

O importante é que o retorno do IRelatorioContas,BuscarResumoContas() vai ser usado pelo caso de uso pra gerar um RelatorioContasResponse, sem a necessidade de instanciar Entities e aggregates que por definicao sao altamente consistentes,

[leandrofagundes]

Hmm, não conhecia esse tipo de prática. Talvez eu não consiga assimilar uma Model que não representa nada de verdade no banco de dados.
Existe alguma leitura que tu recomenda ou exemplos que deixem isso visualmente mais claro sem quebrar a clean architecture?

Eu to aqui pensando em como vai ser segmentado esse Model que tu citou.

ps: O lazy loading do EF não é recomendado?? Pq tu não usa o Linq to Entities pra montar tuas consultas, preferindo o SQL crú?

[ivanpaulovich]

Existe alguma leitura que tu recomenda ou exemplos que deixem isso visualmente mais claro sem quebrar a clean architecture?

O padrão CQRS tem varios sábores de implementacao, e um deles é a criacao de um Model para Leitura, e um Model para Escrita. No seu caso, eu imagino que o Model de Leitura sao as classes que representam as views do BD.

O lazy loading do EF não é recomendado?? Pq tu não usa o Linq to Entities pra montar tuas consultas, preferindo o SQL crú?

Isso depende. LazyLoading é quase mágica, não gosto quando magica se infiltra no Application+Domain.

[rodrigoreis]

E ai @ivanpaulovich como estão as coisas?

Estou usando esta arquitetura como arquitetura de referência para um cliente, muito obrigado pelo projeto. Aproveito para acrescentar que no nosso desenho estamos utilizando uma estrutura de integração via gateways, estes estão sendo tratados como possíveis dependências de serviço, ou seja, o serviço agora quando precisa de uma integração externa injetamos o gateway que implementamos ainda na camada de infra.

O que acha?

Forte abraço.

[vmamore]

Fala @rodrigoreis , fiquei curioso para entender o que essa abordagem resolve, porém não entendi muito bem como está a implementação. Poderia explicar melhor ou mostrar o desenho? Valeu!

[ivanpaulovich]

E ai @ivanpaulovich como estão as coisas?

Estou usando esta arquitetura como arquitetura de referência para um cliente, muito obrigado pelo projeto. Aproveito para acrescentar que no nosso desenho estamos utilizando uma estrutura de integração via gateways, estes estão sendo tratados como possíveis dependências de serviço, ou seja, o serviço agora quando precisa de uma integração externa injetamos o gateway que implementamos ainda na camada de infra.

O que acha?

Forte abraço.

Olá @rodrigoreis, tirando o frio de lascar está tudo ótimo por aqui :)

Me corrija se eu entendi errado.

1. Você implementa a comunicação com os Gateways (Web Services, Cloud, HTTP) na camada de infraestrutura?
2. Você injeta a interface desses servicos nos casos de usos?

Sim sim, isso é bem semelhante ao que propomos no Manga. Poderia compartilhar mais detalhes?
Abraço!

[mviegas]

Fala Ivan, tudo bem?

Uma dúvida que surgiu aqui enquanto eu lia o código: os UseCases não são parte do domínio da aplicação e, portanto, deveriam estar no layer de domínio e não no de aplicação?

[ivanpaulovich]

Hey @mviegas!

• Na camada Application eu coloco as regras de negocio concretas e mais especialistas para essa Aplicação (leia o sofftware em si) ou que consomem recursos externos (UnitOfWork faz commit no banco).
• Na camada Domain eu implemento os diversos Bounded Contexts e suas Agregacoes, Os domain services fazem operacoes apenas em memoria, e se eu quisesse poderia extrair o Domain e montar uma aplicacao bem diferente (Domain é altamente abstrato).
• Os UseCases acessam multiplos BCs.

Uma dúvida que surgiu aqui enquanto eu lia o código: os UseCases não são parte do domínio da aplicação e, portanto, deveriam estar no layer de domínio e não no de aplicação?

O RegisterUseCase usa Customer, Account and Security e acho que ficaria dificl dizer em qual BC cada caso de uso deveria ser implementado. Minha solucao foi coloca-los numa camada mais externa que pode acessar qualquer BC.

Esse modelo serve pra mim. Algum exemplo que possa compartilhar?

[mviegas]

Obrigado pela resposta! Uma abordagem que eu venho utilizando é a seguinte:

Os meus UseCases estão na minha camada de domínio. Quando ocorre de um UseCase precisar acessar um outro BC, isso é feito através de um serviço de domínio. Pensando dessa forma, o BC de Customer teria um serviço de domínio IRegisterCustomerDomainService com os seguintes métodos:

• um OpenCheckingAccount que me retornaria o accountId
• um CreateUserCredentials que me retornaria o user

De forma semelhante, o Core/SharedKernel do meu Domain teria um IUnitOfWork que seria responsável por garantir a integração entre os BCs numa mesma transação (pensando num caso onde ACID seria possível).

Nesse caso o RegisterUseCase estaria no domínio e acessaria o meu IRegisterCustomerDomainService para executar os comandos/queries nos outros BCs.

Por fim, dessa forma, aconteceria o seguinte:

• a implementação de IUnitOfWork estaria no layer de Infrastructure
• a implementação do(s) IRegisterCustomerDomainService estaria em um layer de Services ou até mesmo no de Application
• com isso, o RegisterUseCase ficaria no BC de Customer e a interação com os outros BCs seria através desse serviço de domínio.

O que acha dessa abordagem?!

[leandrofagundes]

Opa @ivanpaulovich , eu tenho percebido que muitos awaits possuem o configureawait(false) no final.
Eu dei uma pesquisada e em resumo eu vejo o pessoal explicando que um ConfigureAwait(true) é quando você vai envolver UI e o false quando é mais dlls de backend, mas mesmo ouvindo e reouvindo as explicações não consegui compreender de fato a diferença e pra que serve.
Você poderia explicar?

[ivanpaulovich]

Ola @leandrofagundes,

Recomendo consultar o https://devblogs.microsoft.com/dotnet/configureawait-faq/ pois isso depende do tipo de aplicações que voce esta desenvolvendo, em geral temos:

Ao usar ConfigureAwait(true) o processamento assíncrono, seja esse realizar uma requisição HTTP ou executar uma consulta em banco de dados sera executado usando o mesmo Thread (ou Contexto de Sincronização) em uso no momento da chamada. Se o programa realizar muitas chamadas assíncronas demoradas a aplicação pode atingir um Deadlock.

Ao usar ConfigureAwait(false) o programa ira executar o código assíncrono em um Contexto independente. O que usa melhor os recursos do sistema.

[pauloafpjunior]

Olá @maikmb,

O que o projeto mais precisa no momento é de uma interface de usuário (React, Blazor, etc). Se tiver interesse nisso seria bem vindo.
No mais, fazendo perguntas já está ajudando bastante.

Falando em UI, @ivanpaulovich, você acha possível ou que há algum benefício em aplicar os princípios de Clean-arch em código front-end? Conhece algum projeto interessante com Angular, por exemplo?

E parabéns pelo projeto. Estou estudando-o nos últimos dias e tenho gostado bastante.

[ivanpaulovich]

Hey @pauloafpjunior, eu acho que a produtividade no frontend é muito dependente de frameworks e que vale a pena usufruir desse beneficio.

Não conheço uma referência em Angular.

Obrigado e seja bem vindo :)

[pauloafpjunior]

Hey @pauloafpjunior, eu acho que a produtividade no frontend é muito dependente de frameworks e que vale a pena usufruir desse beneficio.

Não conheço uma referência em Angular.

Obrigado e seja bem vindo :)

Eu que agradeço a reposta e parabéns pelo trabalho, @ivanpaulovich. Você tem algum livro publicado sobre o assunto? Acho que terias muito a contribuir...

[agpcardoso]

Olá, o que difere os UseCases dos Application Services do DDD?

[ivanpaulovich]

Olá, o que difere os UseCases dos Application Services do DDD?

Ola @agpcardoso, essencialmente Application Services e Casos de Usos são pontos de entrada para a execução das regras de negócio. Fisicamente são a mesma coisa: interfaces + implementação.

No ponto de vista de Clean Architecture, as regras de negocio são organizadas ao redor dos casos de uso. Essa característica implica:

• na organização de pastas.
• no baixo desacoplamento entre casos de usos.
• na nomenclatura.

[marcrib]

@ivanpaulovich Olá, parabéns pelo projeto. Verifiquei em outra issue o motivo de você não usar o MediatR (não ter dependências).
Mas como você trataria eventos de domínio? Por exemplo, como notificaria um novo depósito por e-mail?

[leandrofagundes]

@ivanpaulovich Olá, parabéns pelo projeto. Verifiquei em outra issue o motivo de você não usar o MediatR (não ter dependências).
Mas como você trataria eventos de domínio? Por exemplo, como notificaria um novo depósito por e-mail?

@marcrib nesse caso, creio que a melhor saída seja você injetar a depêndencia necessária.
Crie uma interface na sua aplicação/domínio com os métodos necessários, e a implementação na camada mais externa.
Dessa forma, sua aplicação/domínio dependem apenas da Interface, e sua classe de implementação que de fato depende de outros frameworks, está na camada mais externa. Se aplicar certinho, o dia que for necessário trocar seu serviço de eventos, basta que o novo implemente a interface da mesma forma e esse novo serviço seja injetado ao invés do anterior.

[marcrib]

@ivanpaulovich Olá, parabéns pelo projeto. Verifiquei em outra issue o motivo de você não usar o MediatR (não ter dependências).
Mas como você trataria eventos de domínio? Por exemplo, como notificaria um novo depósito por e-mail?

@marcrib nesse caso, creio que a melhor saída seja você injetar a depêndencia necessária.
Crie uma interface na sua aplicação/domínio com os métodos necessários, e a implementação na camada mais externa.
Dessa forma, sua aplicação/domínio dependem apenas da Interface, e sua classe de implementação que de fato depende de outros frameworks, está na camada mais externa. Se aplicar certinho, o dia que for necessário trocar seu serviço de eventos, basta que o novo implemente a interface da mesma forma e esse novo serviço seja injetado ao invés do anterior.

Praticamente criando um adapter para o BUS ?

[ivanpaulovich]

@ivanpaulovich Olá, parabéns pelo projeto. Verifiquei em outra issue o motivo de você não usar o MediatR (não ter dependências).

Mas como você trataria eventos de domínio? Por exemplo, como notificaria um novo depósito por e-mail?

@marcrib nesse caso, creio que a melhor saída seja você injetar a depêndencia necessária.

Crie uma interface na sua aplicação/domínio com os métodos necessários, e a implementação na camada mais externa.

Dessa forma, sua aplicação/domínio dependem apenas da Interface, e sua classe de implementação que de fato depende de outros frameworks, está na camada mais externa. Se aplicar certinho, o dia que for necessário trocar seu serviço de eventos, basta que o novo implemente a interface da mesma forma e esse novo serviço seja injetado ao invés do anterior.

Praticamente criando um adapter para o BUS ?

Hey @marcrib, assim como o @leandrofagundes ja explicou. O caso de uso pode delegar a o envio de notificações para a implementação da interface INotificationService definida na sua Application 😄

[marcrib]

@ivanpaulovich entendido, rs.

E por falar em interface e abstração.

Visto que a ideia da arquitetura hexagonal é não ter dependência, podendo seu domain trabalhar 'sozinho'.

As interfaces de UseCase não deveria encontrar-se no projeto Domain?

[leandrofagundes]

Oi @marcrib vou me meter de novo hehe.

Teu negócio é dividido em duas camadas até onde entendo, uma camada de aplicação e uma de domínio.
Ambas as camadas tem regras, mas cada uma respeita um nível diferente.

Os casos de uso contém regras da camada da aplicação, não do domínio.
Vamos tentar exemplificar:
Tu tem dois casos de uso, um de cadastro de pessoa física e um de cadastro de pessoa jurídica. Eles são casos de uso diferentes pois no nosso exemplo atendem atores diferentes. O domínio da base é um só, PESSOA, mas ele pode vir com regras diferentes.
Se for no caso de uso de pessoa física, tu vai validar se tem rg e cpf. Se for pessoa jurídica, CNPJ e IE.
Essas regras para cadastrar essa pessoa pra cada caso de uso, ficam na camada de aplicação, ou seja, aonde estão os casos de uso.

Agora, existe uma regra mais embaixo disso. Independente do caso de uso, pode ser o número de caracteres de uma propriedade (nome pode ter no máximo 200 caracteres e no mínimo 3), qualquer coisa que seja referente ao objeto pessoa de forma geral, e não para um caso de único específico. Sei lá, você só pode alterar dados de uma pessoa ATIVA, independente se é física ou jurídica, então essa validação fica no domínio. Se alguma propriedade do PESSOA for alterada, ele valida o status. Ao invés de ser validado no caso de uso, a regra é de domínio.

Lendo agora, percebo que meu exemplo talvez tenha sido um pouco infeliz, mas não consigo pensar em outros exemplos agora... o que fica é a ideia que existem dois níveis de regra. A regra da aplicação, que é controlada dentro dos casos de uso, e a regra do domínio, que sempre precisa ser validada, independente de qualquer caso de uso.

[leandrofagundes]

@ivanpaulovich tem algumas coisas que ainda não entram nessa cabecinha gigante aqui 😢

Eu tenho uma entidade (Oferta) que só deve ter dados em uma tabela secundária (OfertaRegiao) quando ela de fato for lançada.
Ou seja, eu crio a oferta, dados dela, título, etc e deixo tudo pronto, mas ela ainda não foi lançada em nenhuma região do país.

Essa oferta fica disponível em uma lista de ofertas, e todos que querem adotar ela, executam o método Lançar na oferta, gerando um registro de OfertaRegiao. Esse registro tem o ID da oferta e os dados da região que ela vai cobrir (geolocation, etc).

Agora falando da estrutura. Meu OfertaFactory tem um Criar para criar a oferta e um Lancar para lançar na região (recebe a oferta e uma entidade de região).
Mas eu também preciso mudar uma propriedade na entitida Oferta, ficando assim:

oferta.Lancar();//muda o status
var ofertaRegiao = ofertaFactory.Lancar(oferta,regiao);//cria um ofertaRegiao que vai pra base

ofertaRepository.Update(oferta);//atualiza a oferta que sofreu alteração no status
ofertaRepository.AdicionarRegiao(ofertaRegiao);//que adiciona a região para oferta

O que me incomoda é ter que manualmente chamar o model oferta para lançar, e depois chamar o factory para criar a região (chamando um lançar duas vezes).

Desculpa se não ficou clara a explicação, mas parece que tem algum code smell ai no meio.
Pode me dar um norte?

[agpcardoso]

No blog do Uncle Bob e no livro o primeiro circulo interno diz respeito a Entidades com regras de negocio, estou até lendo o livro novamente mas não lembro de na primeira leitura ter visto nenhuma menção de que na camada mais interna deveria ser usado DDD, porém tenho visto algumas pessoas falando sobre o uso do DDD na camada interna e os use cases fazendo o workflow de todas as abstrações e chamadas a essas regras.

Minha duvida é se o @ivanpaulovich e também o pessoal que está utilizando clean architecture a mais tempo em seus projetos, como estão organizando a camada mais interna que diz respeito as Entidades?

1- São entidades soltas com regras de negocio que dizem respeito somente a elas e quando se trata de regras de negocio que envolvam 2 ou mais entidades deixa para o Use Case ou Cria-se Domain Services qdo necessário?

2- Vcs agrupam as Entidades em Agregados respeitando as regras do DDD, onde todas as propriedades da entidade são "private set" e a criação de agregados se dá por factory ou construtor e a comunicação entre diferentes agregados se dá pelo AgregateRoot ou não se preocupam com isso?

[ivanpaulovich]

Ola @agpcardoso!

Espero que estejam todos bem!

Obrigado por compartilhar suas dúvidas e creio que mais pessoas irão se beneficiar da discussão.

1- São entidades soltas com regras de negocio que dizem respeito somente a elas e quando se trata de regras de negocio que envolvam 2 ou mais entidades deixa para o Use Case ou Cria-se Domain Services qdo necessário?

Sim. E bem por ai! Os agregados devem encapsular regras de negocio menores, reusáveis e que afetam as entidades internas.

2- Vcs agrupam as Entidades em Agregados respeitando as regras do DDD, onde todas as propriedades da entidade são "private set" e a criação de agregados se dá por factory ou construtor e a comunicação entre diferentes agregados se dá pelo AgregateRoot ou não se preocupam com isso?

Depende. Eu começo um projeto e não me preocupo com AggregatesFactories (estes surgem a partir de um modelo mais maduro) e são apenas uteis em aplicações que tem muita mudança de estado. Eu diria que aplicações menores, que fazem mais leitura de dados eu não introduzo um AggregateFactory.

---

Eu sugiro começar uma aplicação seguindo TDD-Outside nos casos de uso e evoluir os Aggregates em iterações posteriores. Caso tenha um tempo assiste essa serie https://www.youtube.com/watch?v=daStZZo5Zew&list=PLY9iz4il6pyOl93xDVouXscaoA_WrjBiM
ou acompanha pelos slides https://speakerdeck.com/ivanpaulovich

//Ivan

[marcrib]

Olá @ivanpaulovich

Eu não costumo usar Repository, pois acredito que o EF já implementa o repository pattern.

Mas tenho utilizando com outra abordagem

Eu crio um Repository e crio métodos de extensão para implementar novas consultas ao invés de ficar herdando e criando.

Estes métodos de extensão poderiam estar na camada de Application?

Também pensei em usar uma Interface IDataContext e usar DbSet, mas aí eu teria que colocar como dependência no Application o EF

[leandrofagundes]

Desculpa me meter @marcrib, mas se tu tem uma referência do EF na tua camada de aplicação, tens um problema bem grande de arquitetura. Tu tá gerando uma dependência em uma tecnologia, e não entendi como ele teria o repository Pattern.
Talvez eu tenha entendido muito errado teu cenário, mas tive essa impressão, desculpa se me equivoquei

[marcrib]

Oi @leandrofagundes , aqui todos estamos para aprender, rsrsrs. Eu expliquei na resposta para o Ivan

[ivanpaulovich]

Olá @marcrib,

Poderia compartilhar um código com a gente?
Se eu entendi bem esses métodos de extensão teriam acesso ao DBContext que ao meu ver é uma dependência tecnológica, logo não implementaria na camada de aplicação.

@leandrofagundes,

Há uma implementação alternativa que considera as interfaces do EF abstrações que podem ser usadas por casos de uso.

[marcrib]

Olá Ivan.

Vamos ponderar alguns pontos, acredito que não fui claro na minha pergunta.

1 - EF já implementa o repository pattern

O Entity Framework já é uma implementação de UnitOfWork (DbContext) e também do repository pattern (DbSet)
Essas duas abstrações são os responsáveis para acesso aos dados em nosso banco de dados.
Sendo assim, não seria muito interessante o uso de Repository Pattern com o EF, criando uma abstração de uma abstração.

Entretanto podemos criar uma Interface para nossos testes, algo tipo isso:

public interface IDataContext 
{ 
    DbSet<MeuModel> MeuModel;
    int SaveChanges();
}

Mas ao usarmos essa interface, acabamos tendo que expor em nossa camada de aplicação o EF (Por causa do namespace do DbSet), o que seria um grande erro.
(Não sei se de arquitetura ou de implementação)

2 - Para contornarmos os erros citados acima, podemos usar um Repository com as operações padrões (Generic).
Entretanto, quando precisamos de um novo método, EU acho errado ter que ficar extendendo novamente toda vez o Repository. (Herança)

Ex:

public class ClienteRepository: Repository<Cliente>
{
   //aqui criamos novos métodos.
}

Na minha concepção ficaria mais elegante o uso de extensions methods, exemplo:

public static class ClienteRepositoryExtensions
{
    public static Cliente BuscarPorNome(this Repository<Cliente> repository, string nome)
    {
        return repository
            .Query(x => x.Nome == nome).FirstOrDefalt();
    }
}

[leandrofagundes]

Hehe show! Vou acompanhar pra ver a resposta dele e aprender mais também!