#repository_pattern — Public Fediverse posts

Развитие FastAPI приложения в ходе разработки production-системы

Полтора года назад я написал о своём подходе к структуре FastAPI-приложений. С тех пор два крупных проекта, production и несколько архитектурных граблей заставили меня многое пересмотреть. В этой статье расскажу, что изменилось и какие решения действительно упростили мне разработку.

https://habr.com/ru/articles/1073130/

#FastAPI #Python #SQLAlchemy #Docker #Clean_Architecture #DDD #Repository_Pattern #Unit_of_Work #backendразработка #архитектура_ПО

Generic Repository<T> обещал три вещи — не сдержал ни одной и забрал доменную модель

Сколько раз вы реально меняли базу под приложением? Generic Repository – первое, что тащат в проект, и последнее, в чём сомневаются, – держат ровно ради этого. У меня за карьеру смена базы случилась дважды, и оба раза репозиторий полетел в корзину вместе со всем слоем. Это лишь первое из трёх обещаний, которое он не сдержал, а по дороге тихо забрал доменную модель. Как именно – на реальном кейсе с Mongo, и чем мы его заменили.

https://habr.com/ru/articles/1047524/

#Generic_Repository #Repository_pattern #репозиторий #антипаттерн #агрегаты #EF_Core #MongoDB #анемичная_модель #чистая_архитектура #ddd

Почему я перестал передавать Spring Pageable в контракты слоя приложения

Контракт use case должен описывать потребность приложения, а не API выбранного persistence фреймворка. Spring Data пагинация хорошо работает в CRUD приложениях. Для многих проектов Pageable в application service — это разумный компромисс. Проблема возникает, когда Pageable становится частью публичного контракта use case.

https://habr.com/ru/articles/1044352/

#Clean_Architecture #Pageable #pagination #Repository_Pattern #CQRS #Read_Model #JDBC #java

Repository Pattern в управлении базами данных: пример интеграции NocoDB в Django

Классический сценарий: есть

https://habr.com/ru/companies/selectel/articles/965536/

#nocodb #repository_pattern #django #fastapi #rest_api #бизнеслогика #хранение_данных

[Перевод] Транзакции в БД на Go с использованием многослойной архитектуры

Когда я присоединяюсь к новой компании, меня часто посещает синдром самозванца. После всех этих собеседований кажется, что парни знают, что делают и я смиренно настравиаюсь учиться у лучших. Однажды, я столкнулся с инцидентом на проде и обратился за помощью к самому опытному инженеру. Он пришел на помощь и с легкостью изменил значение в БД с помощью... ручного обновления. 🤯 Проблема заключалась в том, что набор SQL-обновлений не был выполнен внутри транзакции. Работа в новой компании — это всегда увлекательно. Я осознал, что даже если какой-то аспект кажется простым, например, SQL-транзакции, его легко упустить из виду. SQL кажется чем-то, что мы все хорошо знаем, и мало чем может удивить. (Ему уже 50 лет!) Возможно, пришло время пересмотреть подходы, так как мы уже прошли фазу хайпа по поводу NoSQL, и снова возвращаемся к “используйте просто Postgres”, а иногда и к “SQLite тут за глаза”. Я хочу сосредоточиться на том, как правильно применять транзакции в коде, а не на их технической сложности. Когда ваш проект становится больше, вы начинаете разделять логику и код базы данных с помощью слоев. Однако это не всегда так просто, как кажется. Вы можете запутаться и столкнуться с неочевидными ошибками. Основной принцип многослойной архитектуры заключается в разделении критически важных частей кода (логики) от деталей реализации (например, SQL-запросов). Одним из способов достижения такого разделения является паттерн «Репозиторий». Однако, наиболее сложным аспектом такой архитектуры является обработка транзакций.

https://habr.com/ru/articles/848596/

#transactions #repository_pattern #transaction_manager #layers

Как сменить технологию и не закопаться в рефакторинге: опыт внедрения DDD в проект на FastAPI — Часть 1

Привет, хабравчане! В серии статей расскажу, что такое DDD (domain-driven design) и какие у него преимущества и недостатки. Разберемся, когда применять подход и как сочетать его с FastAPI , популярным ASGI фреймворком на Python. В этой части рассмотрим паттерны проектирования Repository и Unit of Work . С их помощью мы работаем через интерфейсы. Паттерны помогают в разделении кода на слои: основная логика приложения представляется внутренними слоями, а используемые технологии - внешними.

https://habr.com/ru/articles/833720/

#fastapi #ddd #refactoring #repository_pattern #unit_of_work #проектирование #рефакторинг #чистая_архитектура