none
Mapeamento Classes Pessoa, Pessoa Física e Pessoa Jurídica (EF Core) RRS feed

  • Discussão Geral

  • Boa tarde Pessoal,

    Estamos com um problema para resolver no mapeamento de Pessoas, já pesquisamos soluções, mas não encontramos uma que atenda nossa necessidade. Caso alguém já tenha passado por algo parecido e que nos possa dar uma sugestão.

    Estamos utilizando o Entity Framework Core.

    Precisamos resolver o seguinte cenário, o diagrama está mais abaixo:

    A ideia principal é manter um cadastro centralizado, onde é possível obter todas as informações de uma pessoa independentemente do tipo da pessoa, se Representante, se cliente etc.

    Uma situação é que o Representante (SalesRepresentative) tem o primeiro cadastro como Pessoa Física (IndividualEntityData) e posteriormente como Pessoa Jurídica (LegalEntityData), pois ele é admitido sem obter ainda uma empresa, e após um tempo ele abre a empresa e é atualizado o cadastro dele.

    Essa mesma pessoa também pode virar um cliente (Customer) sendo Pessoa Física ou Jurídica e com outros documentos. Então pensamos em criar uma estrutura mais flexível e centralizada, onde utilizamos a mesma Pessoa (Person) e vinculamos aos demais Tipos de Pessoas, SalesRepresentative, Customer, etc.,

    Só que empacamos em onde vincular as entidades Pessoa Física (IndividualEntityData) e Pessoa Jurídica (LegalEntityData) de forma que não fique redundante e fora dos Padrões de Projetos.

    Também pensamos em sempre criar uma pessoa nova para cada tipo de pessoa, mas perderíamos a rastreabilidade das informações.

    Pode parecer algo trivial, mas achamos muita dificuldade em desenhar essa estrutura, Pessoa, Pessoa Física e Pessoa Jurídica, sendo que uma pessoa pode ser Cliente (PF e PJ), Fornecedor (PF e PJ), etc, se puderem nos passar um exemplo de estrutura que já presenciaram, já pode nos abrir mais a mente.

    Aguardo sugestões, muito obrigado!

    quarta-feira, 6 de março de 2019 19:04

Todas as Respostas

  • Olá Bruno, tudo bem?

    Um dos conceitos mais importantes do DDD é o Bounded Context, que defende a visão da entidade no escopo do contexto. 

    Como você mesmo disse, a mesma entidade, em diferentes contextos pode assumir diferentes características. Esse realmente não é um problema simples de resolver, pois cada sistema tem suas particularidades, mas se você puder isolar os bounded contexts sua modelagem deve ficar melhor. 

    O problema é que a implementação não tem um padrão exato.

    Criar uma pasta para cada contexto dentro do seu Domínio pode estruturar bem tudo.

    Talvez criar um serviço para cada contexto, de acordo com a necessidade de cada parte do sistema, pode ser uma boa solução. Mas esse caminho gera mais trabalho, pois seria necessário um projeto novo pra cada contexto.

    O importante é se ater ao conceito, assim você evita a Grande Bola de Lama, tendo em uma classe características de todos contextos (Ter características de PF e PJ na mesma classe, por exemplo, pode deixar o código muito complexo).

    Recomendo esse artigo do Eduardo Pires sobre o tema: DDD - Bounded Context



    quinta-feira, 7 de março de 2019 08:47
  • Oi Bruno, passamos por esta mesma situação e resolvemos da seguinte forma.

    No cadastro de pessoas temos um tipo de pessoa ( PF/PJ )
    Na pessoa temos um campo chamado DOCUMENTO que em função do tipo de pessoa recebe um CPF ou um CNPJ.
    Se esta pessoa física vem a ser proprietário de uma pessoa jurídica então criamos na pessoa jurídica o campo "ResponsavelId" e no cadastro da pessoa jurídica ( no nosso caso loja ) temos então o responsável na tabela LOJAS.

    Como toda pessoa jurídica tem uma pessoa física então atribuímos o vínculo daquela PJ a PF, mas note que isso não é feito na tabela PESSOA e sim na LOJA

    Na tabela LOJA o Id é o mesmo Id da Pessoa ( desde que ela seja jurídica ) e o Id da loja não é auto-incremental. Desta forma fica tudo amarrado.

    No meu caso trata-se de uma aplicação com 17 fábricas, 2200 lojas,1800 proprietários e 8000 vendedores aproximadamente. Note que a hierarquia vem das fábricas para os proprietários, para as lojas e para os vendedores...

    Cenário complexo mas tudo funciona lindo utilizando esse formato.

    Apanhamos na largada para definir o modelo mas foi o melhor que conseguimos não só em termos de estruturação mas também em termos de performance.

    Espero ter ajudado.

    quinta-feira, 7 de março de 2019 14:21
  • Bom dia Rogério, tudo bem?

    Primeiramente muito obrigado pelo retorno.

    Achei muito legal essa abordagem, definir vários contextos e trabalhar de uma forma individual, com certeza iremos estudar esse modelo de implementação e aplicar em alguns módulos críticos, onde caracteristicas de determinadas entidades não sejam compartilhadas, exemplo, Item tem Preço é interessante para contexto de vendas, mas para um contexto de suporte não é interessante ver o preço.

    Agora a dúvida maior nossa é como aplicar essa metodologia diferenciando o tipo de pessoa, por exemplo, como mapear as características da pessoa quando for Pessoa Física ou Jurídica independente do contexto que ela apresente. Pois essas pessoas serão parecidos nos contextos que temos, sendo vendas, faturamento e contas a receber, que são os módulos que estamos desenvolvendo, pois um cliente pode ser tanto PF quanto PJ. Lembrando que as entidade mapeadas no meu diagrama irão se comportar dentro de um mesmo contexto.

    Não sei se ficou confusa minha explicação, resumindo, queria saber qual seria a melhor prática de mapear Pessoa, PF e PJ, se usando herança, composição, etc. e como obter os documentos deles de acordo com o tipo, lembrando que um cliente pode ser PJ e também pode ser PF dentro do mesmo contexto.

    Muito obrigado,

    quinta-feira, 7 de março de 2019 14:36
  • Opa, e aí Bruno tudo bem sim e contigo?

    Eu também tenho dificuldades em desenhar os Contextos Delimitados, mas creio que uma boa maneira é olhar como módulos cada parte do sistema que possua uma responsabilidade bem definida.

    Pela descrição no primeiro post seu, dá a entender que o seu sistema possui um módulo de Vendas, responsável por gestionar todo o processo da venda (Loja, Cliente, Entrega).

    Como o Fernando Bravo comentou, acredito que ter uma entidade Pessoa que possua um Objeto de Valor Documento seja uma boa para representar tanto pessoa jurídica como física. Na classe Documento você pode ter uma propriedade Tipo que define se é uma Pessoa Física ou Jurídica, tendo também as validações encapsuladas ali.

    Além disso, as entidades envolvidas no processo de venda não seriam sempre o Cliente, Loja e Fornecedor ? Se sim, acho que estas entidades devem atender a modelagem.

    Se um cliente Pessoa Física comprar em uma Loja de que ele é dono, temos duas entidades o Cliente e a Loja (que deve ter um responsável como o Fernando citou).

    Agora se o seu sistema tenha outros módulos como por exemplo Fornecimento que gestiona a logística de estoque, pode separar uma pasta para esse módulo e tratar das entidades específicas ali.

    Isso é uma possibilidade apenas, como desenvolvedores sempre temos muitas saídas e o importante sempre é atender bem o negócio rsrs então, sem tornar tudo complexo demais, pois complexidade = custo!

    O que acha?

    sábado, 9 de março de 2019 20:35