Seguindo a série de vídeos do Clean Architecture, hoje começaremos a por a mão na massa e por em prática o que foi mostrado no #1 Clean Architecture – 10 centavos de teoria.
Reforçando que quase todas as informações que utilizei nesses estudos eu extrai do livro Arquitetura Limpa do Uncle Bob, se tiver interesse de conhecer livro, compra com meu link da Amazon =)
Definação do Autor
As Entidades reúnem as Regras Cruciais de Negócios da empresa inteira. Uma entidade pode ser um objeto com métodos ou um conjunto de estruturas de dados e funções. Isso não importa, contanto que as entidades possam ser usadas por muitas aplicações diferentes na empresa e são os objetos de negócios da aplicação.
Fonte: Clean Architecture Book (Página 204)
Elas concentram as regras mais gerais e de nível mais alto. No mínimo, são propensas a mudar quando ocorrer alguma mudança externa. Por exemplo, você não gostaria que esses objetos fossem impactados por uma mudança na navegação de página ou na segurança. Nenhuma mudança operacional em qualquer aplicação específica deve influenciar a camada da entidade.
Vídeo Aula
Depois de você ter lido a definição dessa camada direto da fonte, agora você poderá assistir a vídeo aula onde faço do absoluto zero a criação da camada Domain que é chamada de Entities no desenho da Clean Architecture.
Qualquer dúvida, sugestão, crítica ou qualquer sentimento que você tiver, por favor, não deixa de colocar teu comentário aqui no post.
Forte abraço.
Link Repositório: https://github.com/dersonsena/clean-arch-youtube
Muito boa aula!
Gostei principalmente da questão de começar “de dentro pra fora”, não enchendo o projeto de dependências de libs de terceiros desde o princípio. Já começamos a ver o “clean” a partir daí!
Fala Rodrigo, beleza!? Muito obrigado pelo comentário. Hoje quando eu pego projetos que pedem por uma arquitetura mais rebuscada, ou seja, que tem realmente um domínio complexo eu sempre sigo essa linha de raciocínio e vem dando muito certo para mim.
E ae, cabra, tudo bem? Sua série é boa demais. Parabéns! Me ajudou bastante assimilar os conceitos e me encorajou a encarar o desafio de trazer a clean architecture para o nosso dia a dia. Assisti a tua série sobre clean architecture e li o livro do uncle Bob.
Aprendi que não devemos confundir a entity com a model de um framework como o laravel que vem com o eloquent.
A questão que tenho um pouco de dificuldade de entender é: quando minha classe deve ser uma entity (podendo ter atributos e métodos) e quando minha classe deve ser apenas uma espécie de DTO (apenas transportando dados, seja entre camadas ou através do banco de dados) com métodos que o utilizam definidos dentro de uma useCase, por exemplo.
Fala Pedro, tudo bem cara? Que bom que o meu conteúdo te ajudou de alguma forma =)
Não sei se entendi bem sua dúvida, mas tu quer saber quando usar uma Entity ou um DTO? Se sim, vamos lá. Entity é um dos artefatos mais valiosos e importantes da camanda de domínio, possui identidade e tem ciclo de vida, já o DTO ele é uma “sacola descartável” de informações que é jogado de uma camada para outra para promover o desacoplamento.
Se essa não foi sua dúvida, vai respondendo aqui que ajude se puder. Forte abraço