В чем разница между pipelin'ом и декоратором?
К примеру транзакционное поведение можно реализовать через декоратор или же через pipeline как в mediatr. Или же валидация - декоратор или пайплайн.

А я тем временем меньше чем за часик ещё одну лямбду написал - с деплой/дестрой скриптами: typescript+awscli (поверх бойлерплейта с инит-конфигами). Потом за 10 минут сделал ей API gateway. В "холодном" режиме 900ms, в "прогретом" - от 100ms до 400ms.
Используемые сервисы AWS: API Gateway + Lambda + SSM

PostFetcher, PostReader, LastPostsQueryHandler, ...

рид модельки обслуживают определенный юзкейс. Так и называй. LatestPosts, MostPopularPlaces.

По имени модельки получается...

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

$postReader->latestPosts()
$postReader->popularPosts()

А вот если у меня допустим будет отдельная моделька для постов пользователя, то UserPosts.

а что нам говорит про такие вещи SOLID? Какие у тебя будут причины для изменений у этого PostReader?

будешь ли ты бесконечно добавлять методы в него нарушая open/close

Бесконечно не буду... Исходил из того, что модельки одинаковые, зачем их плодить.

не понимаю про "модельки одинаковые зачем плодить"

весьма удобно делать классы-менеджеры и прочие штуки с расплывчатыми границами ответственности. Нэйминг это сложно важно и заставляет думать зачем нужен класс и что он делает, где граница его зоны ответственности. Должен ли один и тот же класс заниматься разными выборками или же нам просто нужен один мэппер который резалт сэт разворачивает в dto и разные запросы в разных классах... а может быть будет $posts->that(new MostPopular())

Последние посты и самые популярные посты возвращают объекты одного и того же класса Post (я этот класс пост рид-моделью называю)

а я называю dto и в целом разницы нет 3 класса у тебя одно и то же dto возвращают или один.

С зоной ответственности сложный вопрос. Основная сложность с неймингом возникает как раз для класс с размытой зоной ответственности, когда в одном классе методы объединены только тем, что возвращают экземпляры одного и того же класса дто

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

по сути нет никаких причин делать это одним классом

Согласен, причин особых нет...
Только лишь объединить под одной крышей методы, чтобы не было куски классов, в которых по одному методу. А так хоть по какому то признаку объединили

ну вот я не понимаю этого стремления)

они могут быть объеденены под одним неймспейсом)

Стремление делать фасады - всё как банда 4х учила 😂