Комментарии 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
Кажется модель ни разу не абстрагирована от бд получилась, а прибита гвоздями к выбранному на уровне схемы типу данных сурогатных ключей. Какое дело Домену до этого?
Как сменить технологию и не закопаться в рефакторинге: опыт внедрения DDD в проект на FastAPI — Часть 1