DTO, schema, model, entity: почему в коде всё называется User

[Andreas_Fogel]

Тема интересная, но тема user объекта, и его дальнейших обвязок entity, решается обычными handlers. Они и дадут тот самый унифицированный синтаксис. Иначе переходите на логическое программирование, где ошибка может быть только в вашей формуле. Также классы в программировании, и особенно в программировании бд, очень странное решение. Если вам и надо передавать информацию быстро, то для этого есть gRPC, RocketMQ и NATS. Также вообще не понятен слой ORM, если у вас и так уже pydantic для валидации используется. Очень много boilerplate слоев в логике. Это же жрет драгоценную ПЗУ на SSD. И замедляет процесс отправки запросов, еще возьмем сюда факт о плохой параллелизации языка python. То уже как бы и не смешно уже.

[alwaysdeterminated]

В комменте сильно смешалось кучу понятий, буду идти по блокам:

тема user объекта, и его дальнейших обвязок entity, решается обычными handlers.

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

Также классы в программировании, и особенно в программировании бд, очень странное решение.

Ну тут ок конечно. Я принимаю мнение как альтернативное, но это уровень религиозных войн. Полмира так работает, многие языки построенны именно вокруг ООП, а не являются функциональными или процедурными.

Если вам и надо передавать информацию быстро, то для этого есть gRPC, RocketMQ и NATS.

Этот тезис не относится к проблеме в статье. gRPC, RocketMQ и NATS тоже решают другую задачу: транспорт, RPC или обмен сообщениями.
Они не отвечают на вопрос, чем именно является User внутри приложения. Даже поверх всех перечисленных решений можно столько разных объектов и имен накидать, что потом разобраться будет также сложно, как в примерах из статьи.

Также вообще не понятен слой ORM, если у вас и так уже pydantic для валидации используется.

Pydantic отвечает за валидацию и сериализацию данных.
ORM — за маппинг состояния в реляционную БД, связи и работу с изменениями.
Можно писать без ORM, через SQL или query builder, но это отдельный архитектурный выбор и он никак не противоречит наличию Pydantic в проекте.
В общем это два абсолютно разных инструмента сделанных под разные цели.

Очень много boilerplate слоев в логике. Это же жрет драгоценную ПЗУ на SSD.

Очень странный тезис. Это вообще не главный критерий. Главный вопрос — где проходят границы изменения и насколько явно код показывает эти границы, чтобы программисту было удобно.
Если бы мы гнались за тем, сколько весит исходный код, то вряд ли писали бы на питоне. Да и это странный тезис для оценки архитектуры в любом языке и проекте.

еще возьмем сюда факт о плохой параллелизации языка python.

К теме статьи это почти никак не относится. Большинство запросов упирается в I/O: БД, сеть, файловое хранилище. GIL не главный аргумент против DTO и тем более против грамотной архитектуры.