Comments 12
Плохой рекламы не бывает) Спасибо за упоминания!
Почему используется старый вариант типизации с List, Optional, Dict и прочим, вместо list | dict?
Так же не понятно зачем в возвращаемых типах указывать имя класса в кавычках
Действительно ли в питоне нужны классы фабрики? Почему не обойтись функцией, если прям будет нужда
Почему используется старый вариант типизации с List, Optional, Dict и прочим, вместо list | dict
Так же не понятно зачем в возвращаемых типах указывать имя класса в кавычках
Тупая привычка со времен старых версий питона. Но, спасибо за замечания, внесу в ближайшее время корректировки.
Действительно ли в питоне нужны классы фабрики? Почему не обойтись функцией, если прям будет нужда.
Время жизни фабрики может быть больше самого Usecase на уровне Application, а также могут понадобится параметры, которые непосредственно не участвуют в создании сущности или которые меняют логику создания исходя из конфигурации приложения (например мы потом поймем, что необходимо будет перевести фабрику в абстрактный класс, а уже считывание конфигураций реализовать на уровне Infra).
Я с вами полностью согласен, можно обойтись функцией в 100% случаев, а если уж прям захочется расширить сценарий, то у нас на этот случай есть прекрасные декораторы. Но статья для новичков и я подумал, что возможно материал будет перегружен таким образом. В целом раз есть замечание и оно безусловно крутое, стоило бы раскрыть мысль более подробно или вообще опустить их написание, пока не придем к слою Application.
Спасибо)
Спасибо за ответ. в целом считаю, что фабрики не нужны в большинстве случаев, а там где и нужны - можно обойтись методом класса, что бы не плодить лишний код и если вам не нравится функция )
А ещё вопрос. что если нам понадобится получить все кадры с камер на втором этаже, к какому репозиторию будет относится метод получения таких данных?
А ещё вопрос. что если нам понадобится получить все кадры с камер на втором этаже, к какому репозиторию будет относится метод получения таких данных?
Если мы говорим про Read запросы, то ни к какому. Лучше и правильней создавать отдельные Query обработчики (Application) для сложных запросов, которые на вход получают DTO, и на выход сразу отдают DTO. Репозиторий нужен для того, чтобы извлечь из хранилища целостную сущность, произвести над ней какие-то операции и сохранить.
В будущем я планирую использовать Yolo и еще одну простую нейронку для дообработки (как раз здесь и будет фабрика нужна для сборки объекта). Скорость обработки там примерно 400мкс на каждый кадр. Если мы будем собирать кадры в сущность при каждом HTTP GET запросе, то каждый такой запрос будет супер медленно обрабатываться, а все преимущества того же Timescale улетучатся. С другой стороны, процесс самой обработки видео уже будет более сложным и он будет охватывать изменение нескольких сущностей, где важно собрать целостный объект, но там уже будут более простые запросы к БД.
Вообще очень интересный вопрос, которым я тоже задавался, но почему-то его не осветил(( Притом вопрос "А на фига все это?" сразу же всплывает на каком-нибудь TODO или интернет-магазине, ведь там и предлагают чаще всего использовать для Read моделей репозитории. Жаль, что этот момент прошляпил... Сделаю работу над ошибками прям здесь или в следующей статье. Большое спасибо.
Добавил в закладки. Один момент хотел уточнить, разве правильно все эти сервисы и репозитории пихать в домен (в папку domain в данном случае)?
Сам пока разбираюсь со всем этим. Мне нравится verical sliced подход, где мы объединяем все слои внутри одной бизнес-сущности, то есть services/, api/, domain/ внутри какого-нибудь User/
Спасибо) Вторая уже на подходе, думаю завтра послезавтра опубликую, очень мотивируют такие вопросы)
Смотрите, есть сервисы и репозитории домена, которые напрямую работают с сущностями и объектами домена, а есть сервисы, репозитории уровня приложения (Application). Приведу примеры:
Сервис поиска объектов по картинке: получает данные из сущности VideoFrame (доменный объект) -> ищет объекты на картинке в своей реализации -> возвращает список распознанных объектов (тоже доменный уровень)
Сервис рисования рамок на картинках. Тут уже нет ответственности домена, сам сервис никак домен не меняет и он даже не нужен для его работы.
С последним согласен полностью, это впоследствии очень упрощает жизнь, но в таком случае необходимо определять Bounded Context, работать через аггрегаты и вводить событийную модель. Но это очень сложно пока в рамках данного гайда.
Почему вы используете @staticmethod вместо @classmethod для фабричных методов value-object'ов?
Ведь @classmethod практичнее, он корректно работает при наследовании и позволяет создавать экземпляры через cls, не привязываясь к конкретному имени класса.
FastAPI: Гайд по нормальной структуре для новичков (Часть 1. Слой домена)