Там будет под каждый тип отдельный агрегат контрактора

Если у тебя есть в системе понятие контрактор, то я бы так не делал

Если не делать агрегаты - возвращаемся тогда к вопросу сохранения транзакционного :(

Почему не делать, сделать контрактора и в нем embedded vo

Но этот embedded entities может быть только 1 - либо это физик, либо организация, либо ип, либо самозанятый..

... или сделать для каждого отдельно:

class Contractor {
  private $fizik;
  private $org;
  private $ip;
  private $selfemployed;
}

?

то есть три из них будут null, а один будет заполнен. В зависимости от типа контрагента.

Зачем вообще null поля хранить? ) Лучше пусть оно отсутствует

Да, это VO, есть общие поля контрагента, есть объекты-значения fizikInfo, orgInfo, ipInfo и поле contractorType

А с точки зрения производительности не будет проблемой? Это ведь ORM придётся при получении этих агрегатов джойнить все эти 4 таблицыю

Join не проблема.

Это одна таблица по дефолту

почему одна?
для каждого типа свои поля и под каждый тип есть таблица в дополнение к основной с контрагентами

Если орм позволяет разруулить embedded в разные таблицы, то можно и так

пошёл изучать))

Спасибо за советы! Когда начинаешь менять подходы, в теории красиво, а на практике миллион вариантов как можно сделать и не понятно что выбрать :)

Понял, спасибо)

Ещё тогда вопрос. Под каждый транспорт нужны шаблоны:
- mail
- sms
- service

Как их лучше реализовать? В одной сущности Template и уже внутри делать гибкий конструктор создания для каждого транспорта:
Template::createEmail(...)
Template::createSms(...)
Template::createService(...)
Если говорит о базе, то при таком подходе таблица будет одна на все типы транспорта.

Либо лучше под каждый транспорт свой шаблон:
new MailTemplate(...);
new SmsTemplate(...);
new ServiceTemplate(...);
При таком подходе все данные будут отделены в свои таблицы.

В дальнейшем могут добавиться типы транспорта: чат, пуш. Я склоняюсь ко второму варианту, но не избыточен ли он?

Нет, не избыточен. Интуиция тебе правильно подсказывает, лучше не пытаться объединять разные по типу данные.

Делай разные таблицы.

class Contractor {
  private $fizik;
  private $org;
  private $ip;
  private $selfemployed;
}

FizikContractor, OrgContractor, EtcContractor?

Или 1 свойство с разными типами

В идеале - 1 свойство с разными типам. Но не понятно как с этим работать в плане ORM, сохранять и восстанавливать