минуту назад ее советовал разработчику )

Добрый день!

Приложение разбито на вот такие слои:

Api
Application
Domain
Infrastructure

В домене у сущностей ID идёт как объект, например, ArticleId.

В Application-слое есть команды, например $changeArticleName->run($id, $newName);

$id, которое передаётся в application слой должно быть ArticleId или можно передавать строку, а в ArticleId уже application-слой сам преобразует внутри?

как хочешь, как удобнее, пофигу.

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

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

слои все ж только горизонтально режут. это "удобное упрощение" но важнее вертикальные границы

У меня получается в API прилетают скаляры (строки в основном), API вызывает одну (пока не требовалось больше) команду из Application-слоя. Выходит что удобнее в команду Application-слоя передавать строку, а сразу после входа - преобразовывать её в объект и дальше только его использовать.

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

вообще не все айдишки у меня достойны того что бы не было просто скаляром)

обычно это хороший повод показать что "а вот эта айдишка сущности - она существует сама по себе и объединяет несколько агрегатов".

То есть как-только получили где-то на входе скаляр - то сразу преобразовываем в формат системы и дальше используем...

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

Понял. Спасибо :)

Или почитать про другие архитектуры?

Обязательно почитаем, спасибо,  за такой прекрасный совет! Сразу видна рука принсипал сеньор лид чиф архитектора L8, нам бы такого хоть одного в компанию, эх!

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

это если ты чет новое делаешь, когда гринфилд

или старое, но с другими условиями

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

Я бы точно не пошёл работать в такую компанию))