смотри. инкапсуляция сама по себе не имеет особо значения. Это инструмент для достижения более великой цели - information hiding

потому что нормальные люди не делают конструкторы которые валятся

потому don't create your aggregate roots

но как тогда нормальные люди проверяют, чтобы бабло не было отрицательным?

об этом и есть статья Уди на тему того что другие агрегаты выступают фабриками для твоих агрегатов

как вариант. Правда это не так удобно может быть, т.к. ограничения на создание приходится держать отдельно от данных

ну пока оно не создано оно не отдельно)

ну это ты про рантайм. А если код смотреть  - оно не так очевидно получается

нужны конкретные примеры. могу сказать что универсального ответа нет.

хде ж я вам реальные примеры возьму, у меня формочки стынут)

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

Int => Error \/ Bablo

ну вот правила эти в коде кому можно дёргать new, а кому нет - было бы неплохо выразить как-то

ну в реальности причин делать new не так много, и обычно это как-то связано логически бизнес логикой... мол... ты ж не будешь просто так создавать что-то...

Мне вот нравится пример - допустим у нас есть стандартная регистрация пользователя с верификацией email-а (потому что на email будут приходить важные вещи и нам важно что бы пользователь не ввел херню - ему же хуже).

В этом случае мы можем создать некий агрегат который будет хранить в себе неподтвержденный email  (UnconfirmedEmail какой, я так себе в нэйминг) и после подтверждения ты можешь использовать этот агрегат что бы сделать какого-нибудь Customer.

В этом случае вся валидация прекондишенов для создания Customer будет происходить в рамках UnconfirmedEmail и причин кастомеру ругаться на email не будет. Так же как и причин по которым ты где-то еще захочешь сделать какого-то другого кастомера с таким же набором ограничений на входящие данные.

Пример может так себе конечно, но смысл в этом. Скрыть информацию о отдельном этапе жизни данных от всей остальной системы. Кастомеру теперь об этом знать не надо. И всем кто работает с кастомером тоже...

для думающих людей это вполне катит, я согласен. Точнее даже для людей, которые пытаются разобраться в процессе
Ну и надо понмать, что new - опасная штука и что её надо встраивать в этот процесс весь
Хороший пример на самом деле

Говномешанина из ооп, функций и  процедур. Но стремительно форматирую мышление и рефачу в сторону ООП.
Понятно что идеального результата  не будет.

а ещё тут может быть проблема, что при создании объекта нам нужен другой объект. Между ними появляется жёсткая связь, идентификатором уже не обойдёшься

ну тут опять же нужны конкретные примеры. во всяком случае я не готов какие-то общие правила формулировать

Понатыкают анемиков по всему проекту и считают что они пошли в ФП