Реализация этого домена:

• Пользователь
• Компания
• Клиент

вы можете рассмотреть два разных подхода:

Первый подход

Этот подход использует ассоциацию. Если вы выберете этот вариант, вам следует вручную связать подходящего (компанию или клиента) с текущим пользователем в зависимости от некоторой логики. Каждый User, вероятно, должен иметь только одно из этих полей в любой момент времени. Компания или Клиент, но не то и другое одновременно.

Пользователь

/** @Entity */
class User
{
    /**
     * @ORM\column(type = "string")
     */
    protected password;

    /**
     * @ORM\column(type = "array")
     */ 
    protected roles;

    /**
     * @ORM\OneToOne(targetEntity = "Company", mappedBy = "user")
     */
    protected Company;

    /**
     * @ORM\OneToOne(targetEntity = "Client", mappedBy = "user")
     */ 
    protected Client;
}

Компания

/** @Entity */
class Company
{
    /**
     * @ORM\column(type = "string")
     */
    protected city;

    /**
     * @ORM\OneToOne(targetEntity = "User", inversedBy = "company")
     */ 
    protected user;
}

Клиент

/** @Entity */
class Client
{
    /**
     * @ORM\column(type = "string")
     */
    protected sex;

    /**
     * @ORM\OneToOne(targetEntity = "User", inversedBy = "client")
     */ 
    protected user;
}

Второй подход

Этот подход использует наследование и кажется более гибким, но имеет свои недостатки.

Пользователь

/** @MappedSuperclass */
class User
{
    /**
     * @ORM\column(type = "string")
     */
    protected password;

    /**
     * @ORM\column(type = "array")
     */ 
    protected roles;
}

Компания

/** @Entity */
class Company extends User
{
    /**
     * @Id @Column(type = "integer")
     */
    protected $id;

    /**
     * @ORM\column(type = "string")
     */
    protected city;
}

Клиент

/** @Entity */
class Client extends User
{
    /**
     * @Id @Column(type = "integer")
     */
    protected $id;

    /**
     * @ORM\column(type = "string")
     */
    protected sex;
}

У вас также есть отношение Один ко многим между Пользователь и Сообщение:

• ОдинПользователь может иметь МногиеСообщения
• ОдинСообщение принадлежит только ОдинПользователь

Использование Первый подход, описанного выше, нормально, но использование Второй подход приводит к проблемам как Доктрина говорит:

persistent relationships defined by a mapped superclass must be unidirectional (with an owning side only). This means that One-To-Many associations are not possible on a mapped superclass at all.