Может лучше уж organization?

А есть ещё эти. Как их.. типа ИП но не ИП.

самозанятые

Во. Они)

С ходу не придумывается... костыли одни

Вот поэтому надо работать с контрагентом, тогда сможешь менять тип.

Само название vo у тебя не отраждает суть. То, что ты назвал LegalPerson - это на самом деле реквизиты юрлица

Мм.. по идее это не сложно, сделать прям в контрагенте метод для смены типа

Подход сам надо сменить, дто будет другое

другое по структуре или по названию?

По структуре и по названию

По названию ок, допустим мы сделаем это реквизитами.
А вот в структуре что поменяется, не понимаю :(

@predvoditelev, я стараюсь закладывать архитектуру, руководствуясь идеей о том, что общая цель проекта будет оставаться той же самой, а требования к нему через некоторое время изменятся полностью, от начала и до конца. И стараюсь сделать так, чтобы в этой ситуации внесение изменений в код не приносило боль 😊 Ибо по моему опыту требования к программе всегда радикально меняются, как бы заказчик (даже если это ты сам) ни был уверен в том, что он хочет в точности то, о чем сейчас говорит.
Пока, правда, рано говорить, насколько такой подход лично у меня удачен, мало времени прошло с тех пор, как начал применять его в проде. Но потенциал вижу большой.

Всё правильно, но я не понимаю как эта теория реализовывается на практике :)

Использованием SOLID по полной, в общем-то)) Перестать жестко связывать сущности, нагружать 1 объект/метод разными задачами, делать stateful сервисы, связывать классы, создавая один внутри другого (вместо new можно использовать DI контейнеры или фабрики). Ну и т.д., и т.п.

Я так и стараюсь)

👍 супер

Правда, я слышал, ты сделал так, чтобы контрагент всегда был с привязанным ООО/ИП/и т.п.)

так это сама его суть, что он ООО/ИП и т д

Ну не может ООО вдруг стать ИП