Как стать автором
Обновить

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

Уровень сложностиСредний
Время на прочтение15 мин
Количество просмотров11K
Всего голосов 17: ↑16 и ↓1+17
Комментарии15

Комментарии 15

Интересно что будет дальше. Когда будете рассматривать усложенные кейсы (по типу догрузить данных из БД), которые всегда сопровождают разработку бизнес-приложений.

И это пока не DDD. На картинке нечто, напоминающее луковую архитектуру. А отделить сущности от таблиц в БД можно и с анемичной моделью.

Спасибо за уточнение! Я пока еще относительно новичок с точки зрения DDD, так что решил поделиться собственным опытом и видением. Буду стараться развиваться дальше!)

Во второй части хочу рассмотреть команды и события, чтобы легко добавлять новый функционал к ендпоинтам (по типу создания celery таски, которая будет отправлять уведомление о том, что пользователю поставили оценку - в рамках данного примера), при этом не меняя основную кодовую базу, а лишь создавая новый Handler и добавляя его в список событий, которые будут вызываться.

Вы в реальной жизни иcпользуете DDD? Ваш пример слишком простой, веселье начинается при усложнении. Второе - работа с БД тут описана, а где бизнес-логика? Как уже написали выше использовать репозитории можно и с анемичной моделью, без всякого DDD.

Да, используем (Как описанные в этой части паттерны UoW + Repository, так команды и события, шину сообщений для работы с ними, о которых расскажу во второй части). Пример специально приведен упрощенный + это первая часть, чтобы не делать статью слишком большой и преподносить информацию порционно.

С точки зрения бизнес логики в данном примере - согласен, добавлю со второй частью. Как пример бизнес логики хочу использовать отправку уведомления на почту пользователя с информацией об оценке, которую ему поставили.

Как я уже упоминал, я являюсь новичком с точки зрения DDD и буду рад советам и конструктивной критике!

о рофл история в тему. у нас пытались внедрить ddd, прикол в том что система - это апи для бэкофис системы с 50 пользователям и крайне низким рпс, зато несколькими сотнями эндпоинтов. Чисто испанские сеньоры ворвались в проект пояснить за технологии, но технологии и купил, а мозг грамотно их применять не купил

Звучит точно как кейс, когда излишняя сложность, пожалуй, не окупается)

Работа ведется через интерфейсы, а не реализации,

Не увидел интерфейсы (protocols в питоне). Или интерфейсами названы абстрактные классы?

Да в данном контексте под интерфейсами подразумеваются абстрактные классы, чтобы явно указать в примерах, какие методы должны быть реализованы. Поскольку, согласно документации (typing.Protocol (an instance of abc.ABCMeta)) Протокол создан на основе метакласса ABCMeta, как и абстрактный класс, то, имхо, для данного примера это не является критом

С точки зрения нейминга согласен с Вами, интерфейсами правильнее будет называть Протоколы

Декларативный стиль маппинга моделей в сравнении с императивным кажется сложным.

В предшествующем блоке кода применён императивный стиль.

Перепутал местами, спасибо, поправил!

ахахах, в пятницу вечером по классике)

class UserVoteModel(AbstractModel):
    voting_user_id: int  # Who votes
    voted_for_user_id: int  # Votes for who

Кажется модель ни разу не абстрагирована от бд получилась, а прибита гвоздями к выбранному на уровне схемы типу данных сурогатных ключей. Какое дело Домену до этого?

Пришлось использовать такой подход как промежуточное решение. По факту, это действительно не задача модели, а информация события, которое должно быть обработано в ходе голосования за пользователя (лайк/дизлайк)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации