Modeling for comprehensive entity registration

Question

I am creating a registration modeling in the most comprehensive way possible. Entities are Person, Natural Person, Legal Entity, Supplier and Customer

Below the entity person. I add the person the contact data and address to facilitate future queries.

public class Pessoa {
    private String ativo;
        private String apelido;
        private Endereco endereco;
        private String dataAtualizacao;
        private String foneResidencial;
        private String nome;
        private String foneCelular;
        private String foneProfissional;
        private String sexo;
        private String dataNascimento;
        private String dataCadastro;
        private String email;
}

Pessoa Tisica is quiet:

public class PessoaFisica {
    private String estadoEmissor;
    private Pessoa pessoa;
    private String RG;
    private String orgaoEmissor;
    private String dataAtualizacao;
    private String paisNascimento;
    private String CPF;
    private Profissao profissao;
    private String localNascimento;
    private String estadoNascimento;
    private EstadoCivil estadoCivil;
}

Legal Person is also quiet:

public class PessoaJuridica extends EntidadeAbstrata implements Serializable {
    private String nomeFantasia;
    private Pessoa pessoa;
    private String Razao;
    private String CNPJ;
}

What is complicating for me is to understand Customer and Supplier.

First, which attributes would differentiate them within the base?

And what I find most difficult is: as mine Cliente or Fornecedor could be PessoaFisica or PessoaJuridica being within the same table.

/********UPDATING********/

When I asked the question I confessed that I was not entirely sure what I was asking. I’ll explain my 'giric' idea better'.

I am trying to create a comprehensive registration model not in the sense of having a model ready and that is fully applied to any business, but in the sense of always having a starting point for any system that I develop. I do not deny that it is a desire a little crazy, masssss

When I asked the question related to Customer and Supplier I did it because when it comes to Person or Legal the thing is clearer, at least for me.

Person Physical CPF, RG, Marital Status etc Legal Person Reason, CNPJ, State Registration etc

When asked about customer/supplier I thought that someone with more experience would identify attributes for these entities more easily.

Anyway, I’m open to ideas and criticism. Let’s see what comes

Thanks!

Answer 1

I believe the way to make it as generic as possible is to keep Pessoa Física and Juridical Person, so that both are People, but the best way to do this is to start drawing as you can see in the Class Diagram below (using your classes as an example):

In this image it is possible to realize that a Person can be any type of person, and each type of person can be defined in the Enum Tipopessoa, this way if in the future the need to add a new type arises, just add the new type in this Enum.

---

HOW IT LOOKS IN THE CODE

This can be written in java with 3 classes and 1 enumerator.

1. Type

   public enum TipoPessoa {
           CLIENTE,
           FUNCIONARIO,
           FORNECEDOR, 
           CONTATO
   }
   

2. Person

   public class Pessoa {
       private TipoPessoa tipoPessoa;
       private String nome;
       private String apelido;
       private Endereco endereco;
       private Date dataAtualizacao;
       private Date dataCadastro;
       private String email;
       private String fone;
   }
   

3. Personal

   public class PessoaFisica extends Pessoa{
       private String rg;
       private String orgaoEmissor;
       private String cpf;
       //demais atributos
   }
   

4. Personal

   public class PessoaJuridica  extends Pessoa{
       private String nomeFantasia;
       private String razaoSocial; //atualmente foi alterado para nomeEmpresarial
       private String cnpj;
       private PessoaFisica contato;
   }
   

---

HOW TO USE

    public class Main {
        public static void main(String args[]){

            PessoaJuridica cliente = new PessoaJuridica();
            cliente.setTipoPessoa(TipoPessoa.CLIENTE);
            cliente.setNome("Exemplo Cliente");
            cliente.setCnpj("123123123123");

            PessoaJuridica fornecedor = new PessoaJuridica();
            fornecedor.setTipoPessoa(TipoPessoa.FORNECEDOR);
            fornecedor.setNome("Exemplo Fornecedor");
            fornecedor.setCnpj("123123123333312");

            PessoaFisica clientePessoaFisica = new PessoaFisica();
            clientePessoaFisica.setTipoPessoa(TipoPessoa.CLIENTE);
            clientePessoaFisica.setNome("Exemplo Cliente Pessoa Fisica");
            clientePessoaFisica.setCpf("12312312333");

            PessoaFisica funcionario = new PessoaFisica();
            funcionario.setTipoPessoa(TipoPessoa.FUNCIONARIO);
            funcionario.setNome("Exemplo Funcionario");

            List<Pessoa> pessoas = new LinkedList<Pessoa>();
            pessoas.add(cliente);
            pessoas.add(funcionario);
            pessoas.add(fornecedor);
            pessoas.add(clientePessoaFisica);

            for(Pessoa p: pessoas){
                System.out.println(p.getNome() + " - " + p.getTipoPessoa());
            }
        }
    }

EXIT

    Exemplo Cliente - CLIENTE
    Exemplo Funcionario - FUNCIONARIO
    Exemplo Fornecedor - FORNECEDOR
    Exemplo Cliente Pessoa Fisica - CLIENTE

Answer 2

Various forms are possible according to the need that is not clear. It could be something like this:

public class Cliente {
    private String CNPJ;
    private String CPF;
    private String Comprador; //só exemplos
    private DateTime UltimaVenda;
}

I put in the Github for future reference.

The first fields should be used exclusively, so it is possible to verify which one is in use by analyzing whether the other is null. If you feel that this is not ideal, that you need something more concrete to validate and avoid accidental changes, you can create a field that tells you whether the person is physical or legal.

Obviously this is a simplification of the class, it would be interesting to have builders and methods that would help the good use of it. Unless it’s pure DTO or something like that, what then has to follow what the database establishes.

Nor will I show the supplier, it’s the same thing, no matter what the type of relationship.

It makes sense, but I can’t guarantee that it will achieve all the necessary goals. It seems to be all right. Maybe it could be better.

The link with Pessoa be by a reference to the object, I do not like it so much. It makes sense, but it can limit some scenarios. In database or other form of persistence this does not work.

I liked that did not use inheritance, I think the composition or the relationship is better in this case. Other people would have done "OOP". It would bring some advantages but would bring disadvantages too. There is no perfect model, have to choose which problems want to deal with.

Some people would prefer to link the objects in reverse. That is, to Pessoa would have an information link with the PessoaFisica or PessoaJuridica. And each of these two would have fields to link with the type of relationship that one has with the entity being registered there in the object, ie, would have a field to link with Cliente, another with Fornecedor, and others as the need arises. This would allow to circulate with the Pessoa by the application and access all information of a specific person. Obviously it would require class change whenever adding a new relation type (actually it is possible to have an auxiliary class to handle this without forcing changes to the existing class).

In the current model the opposite is also valid, although rarer, after all going from the bottom up a change in the types of people would force changes in Cliente, Fornecedor, etc. One day a PessoaEstrangeira, which would force the addition of a field in the class up there.

It is possible to have a standardization of the link information and have only one link field (in the example I used CNPJ And CPF), resolving the issue cited in the preceding paragraph and in the preceding paragraph when it speaks of the addition of relationship types. But if done this, it would be mandatory to have a field telling what kind of person.

I think to give flexibility the ideal is to have links on both sides, ie if you have Pessoa, you access the data from PessoaFisica and of Cliente (only to stay on an example) of that person. If you have an object Cliente, gets the data from PessoaFisica and Pessoa general related to it.

Any questions that might interest you:

• What to do if client can be both PF and PJ?
• It can be considered a bad modeling practice to store all people (customers, employees, suppliers) in the same table?
• Database must follow the OO standard?
• Heritage and Polymorphism
• How Java Constructor Inheritance Works?
• Taking and displaying data from a class attribute (class association)

And my answer here.

If I remember any other details, I’ll put them in later.