Вы начали с DTO, а закончили конечными контрактами конечных сервисов/API. Имхо, именно поэтому DTO и не нужен, т.к. каждый слой, который имеет внешний/публичнвый контракт — это не DTO, а осмысленные структуры (должны быть).
PS:
Меня лично парят префиксы и суффиксы в именах, и меня парит то, что когда они есть — они пролазят везде. Более смышленные девелоперы не уподобляются хомякам, и не делают этих суффиксов/префиксов — но все равно их лепят, и пролазит это везде во всех реинкарнациях.
Если речь о слоеной вверх/низходящей архитектуре то там по определению тока контракты. Какие DTO? Что этими DTO делать? Гвозди забивать?
Если приложение простое, то можно ограничится одним наборов объектов, моделирующих ПО, но, банально расшарить транзацкию у которой есть юзерский комментарий — это уже вызовет кучу проблем.
Как вы не называйте объекты — они появляются исходя из выполняемых операций в системе. Платежная транзакция кстати очень хороший пример — ее ID в процессинге всегда не равен в клиент-банке, и выполняемые действия разные.
А ее уникальность на стороне процессинга... ну. Не такая.
Самое главное, что все отлично ложится на любые задачи, если не пытаться изобретать то, что не нужно. Нужно именно DTO — юзайте. Не нужно? Не юзайте.
