Если по простому, то использовать информационные сообщения (что-то было сделано, ссылка на документацию). Как один из вариантов. Использовать какую-то почтовую рассылку, демонстрационные видео и что-нибудь в этом роде

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

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

ну я вот и хотел послушать чужой опыт :) как это решается в других компаниях

Метрики, интервью с пользователями, опросы, работа с целевой группой.

Идеально иметь для фичи контакты "ранних адаптеров" что бы у них выяснять фидбэк.

Тут важно анализировать зачем им вообще фича и какие проблемы они через них пытаются решать

спасибо! мне нравится идея про ранних адаптеров

всем привет!
такой вопрос - есть 4 сущности - по таблицам в БД - хранящие данные составной сущности.
1. mail_message, хранящая subject и body,
2. mail, хранящая mail_message_id и people_id, которому отправится письмо,
3. outgoing_mail_data, хранящая дополнительные данные типа времени отправки письма, статуса и т.п.
4. incoming_mail_data, хранящая данные полученного письма типа времени получения, адрес отправителя, аттачи и т.п.
На уровне приложения я должен работать с составной сущностью - либо OutgoingMail либо IncomingMail, которая должна агрегировать данные и предоставлять некие действия для работы с ними. Как такую работу лучше организовать? Могут ли помочь какие-то классические паттерны типа Адаптер или Фасад?

ой не надо его агрегатами грузить...

Ладна

это ж лог, а не там "граница транзакций", тупенький круд

должен значит работай. "классические паттерны" да могут помочь, если сфоромулируешь проблему. Пока не оч понятно где она у тебя

Все равно у него задача работать с этими данными как с одной сущностью данных.

Мб ему даже обучная вьюха из бд подойдет

ну так не понимаю в чем проблема. если докттрина проблем не должно быть. если не доктрина то тем более (прячем все в сервис собираем как хотим)

не доктрина, AR (Eloquent). Проблема в том, что нужно в коде приложения во всех местах вместо одной сущности создавать 3, работа со связями с "внешним миром" усложняется

у меня была мысль всю логику обернуть в сервис, а в него передавать необходимые данные, сагрегированные в виде DTO.

В eloquent по-моему привязка к таблице и дальше никак. Наверное, действительно только в сервис оборачивать

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

именно так, поэтому действительно у меня проблема агрегации данных в единую сущность. Тут можно и правда попробовать работать с sql VIEW вместо таблиц

Эти данные нужны только для чтения?