о да немного фп примера бы сюда )

Это ток если язык даёт какие-то возможности полиморфизма

Обычно нет, поэтому там чисто процедурки

Я хочу момент один важный заметить... Процедурный подход или фп или ооп не столь важно (в основном потому что в чистом виде все эти подходы не встретить и возникают сложности с определением). Не зацикливайся на этом. В конце концов "ооп" где message passing это просто вызов процедур не сильно отличается от структурного программирования (Армстронг вообще любил говорить что эрланг это единственный в мире ооп язык по этой причине)

Основная проблема Anemic model обычно только в том что инфраструктура для оной не сильно отличается от инфраструктуры для полноценных доменных объектов. В плане сложности реализации и поддержки. Однако плюсов доменных объектов ты с анемик не получаешь никаких.

Поскольку большинство сегодня юзают готовую инфраструктуру типа универсальных orm вся эта сложность становится скрытой.

Есть и другие проблемы вроде "декомпозиция стэйта под ui, провоцируют логический cohesion, затрудняют анализ того как стэйт меняется. Но все это в целом возможно и с доменными объектами и больше про моделирование данных и декомпозицию. Если скажем разработчик просто начал пихать логику в те же сущности то проблемы не оптимальных моделей данных остаются и может выйти даже хуже чем с анемик.

P.s. Тут вот любят хихикать мол фп с анемичными моделями работает, но это не совсем так.

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

Можно, только не хватает сахара что бы код читаемым оставался да и с типами пока не все хорошо

это да

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

Но это все просто более многословные способы в сравнении

Есть доклад чела который объясняет как процедурный код на фп перекладывать на примере c# и при этом сравнивает с тем же в f# - вывод был "идеи важны но на c# я так не буду делать просто потому что язык не очень подходит и вынуждает много бойлерплейта писать"

А c# язык куда более выразительный нежели пых)

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

В итоге то все эти "хорошо плохо" про контроль как стэйт меняется и изоляцию стэйта. А то что ты значения передаешь между штуками - там максимум про stamp coupling можно переживать

это выглядит так, как будто смс отправляет юзер, а не юзеру

как правильно зависит от того чья история.

Типичная "ошибка новичка" в том что user тут (или sender) это тот же класс User который заказы заказывает, который профили обновляет и т.д.

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

Все так
Жаль, только, "не новичков" мало по такой категоризации)

многие напарываются на проблемы с таким подходом (когда ты еще не дробишь стэйт но пихаешь логику) и начинают "наверное это просто ложная ветвь", некоторые начинают строчить статьи аля "доменные модели нарушают SRP"

отсюда нет желания продолжать эксперементы.

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

Скажем делаешь ты убер...

Трекать текущее местоположение машин и людей - постишь POST запрос, пишешь в сторадж по ключу, можно даже в контроллере. Тут ты не выигрываешшь ни от слоев ни от чего.

Чел меняет свой профиль, добавляет фотки и т.д. - тупой круд. Тупая сущность профиль. Можно и анемик - тут просто полная перезапись стэйта. Тут можно даже в слои чуть-чуть поиграть

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

Резюмируя, доменные события позволяют развязать сущность и логику операции или ряда операций, выполняющихся при отправке сообщения этой сущности. Сам доменный объект поддерживает ряд операций, которые меняют (или не меняют) его стейт, и уведомляет заинтересованные обработчики этого события. Так?