Почему-то мне это показалось само собой разумеющимся, ведь со стороны фронтенда необходимо лишь сформировать запрос по схеме, указав все необходимые для получения данные.
А дальше уже со стороны бэкенда они уже будут собраны через механизм резолверов.
Я согласен, что для простой обработки не обязательно использовать паттерн. Моей задачей было показать пример с грамматикой другого языка, которую можно было преобразовать и интерпретировать)
По-моему, паттерн, заточенный чисто на обработку команд - паттерн «Команда». Ведь его задача именно представлять команды в виде объектов, которые отправляются в том числе в Event loop ОС. Ну и в том же GUI паттерн активно используется (помимо прочих по типу компоновщика или наблюдателя).
Пришлось использовать такой подход как промежуточное решение. По факту, это действительно не задача модели, а информация события, которое должно быть обработано в ходе голосования за пользователя (лайк/дизлайк)
Да, используем (Как описанные в этой части паттерны UoW + Repository, так команды и события, шину сообщений для работы с ними, о которых расскажу во второй части). Пример специально приведен упрощенный + это первая часть, чтобы не делать статью слишком большой и преподносить информацию порционно.
С точки зрения бизнес логики в данном примере - согласен, добавлю со второй частью. Как пример бизнес логики хочу использовать отправку уведомления на почту пользователя с информацией об оценке, которую ему поставили.
Как я уже упоминал, я являюсь новичком с точки зрения DDD и буду рад советам и конструктивной критике!
Спасибо за уточнение! Я пока еще относительно новичок с точки зрения DDD, так что решил поделиться собственным опытом и видением. Буду стараться развиваться дальше!)
Во второй части хочу рассмотреть команды и события, чтобы легко добавлять новый функционал к ендпоинтам (по типу создания celery таски, которая будет отправлять уведомление о том, что пользователю поставили оценку - в рамках данного примера), при этом не меняя основную кодовую базу, а лишь создавая новый Handler и добавляя его в список событий, которые будут вызываться.
Да в данном контексте под интерфейсами подразумеваются абстрактные классы, чтобы явно указать в примерах, какие методы должны быть реализованы. Поскольку, согласно документации (typing.Protocol (an instance of abc.ABCMeta)) Протокол создан на основе метакласса ABCMeta, как и абстрактный класс, то, имхо, для данного примера это не является критом
С точки зрения нейминга согласен с Вами, интерфейсами правильнее будет называть Протоколы
Возможно, стоило упомянуть, спасибо!
Почему-то мне это показалось само собой разумеющимся, ведь со стороны фронтенда необходимо лишь сформировать запрос по схеме, указав все необходимые для получения данные.
А дальше уже со стороны бэкенда они уже будут собраны через механизм резолверов.
👍🏻
Спасибо за Вашу поддержку!
Я согласен, что для простой обработки не обязательно использовать паттерн. Моей задачей было показать пример с грамматикой другого языка, которую можно было преобразовать и интерпретировать)
По-моему, паттерн, заточенный чисто на обработку команд - паттерн «Команда». Ведь его задача именно представлять команды в виде объектов, которые отправляются в том числе в Event loop ОС. Ну и в том же GUI паттерн активно используется (помимо прочих по типу компоновщика или наблюдателя).
👀
Пришлось использовать такой подход как промежуточное решение. По факту, это действительно не задача модели, а информация события, которое должно быть обработано в ходе голосования за пользователя (лайк/дизлайк)
ахахах, в пятницу вечером по классике)
Да, используем (Как описанные в этой части паттерны UoW + Repository, так команды и события, шину сообщений для работы с ними, о которых расскажу во второй части). Пример специально приведен упрощенный + это первая часть, чтобы не делать статью слишком большой и преподносить информацию порционно.
С точки зрения бизнес логики в данном примере - согласен, добавлю со второй частью. Как пример бизнес логики хочу использовать отправку уведомления на почту пользователя с информацией об оценке, которую ему поставили.
Как я уже упоминал, я являюсь новичком с точки зрения DDD и буду рад советам и конструктивной критике!
Спасибо за уточнение! Я пока еще относительно новичок с точки зрения DDD, так что решил поделиться собственным опытом и видением. Буду стараться развиваться дальше!)
Во второй части хочу рассмотреть команды и события, чтобы легко добавлять новый функционал к ендпоинтам (по типу создания celery таски, которая будет отправлять уведомление о том, что пользователю поставили оценку - в рамках данного примера), при этом не меняя основную кодовую базу, а лишь создавая новый Handler и добавляя его в список событий, которые будут вызываться.
Звучит точно как кейс, когда излишняя сложность, пожалуй, не окупается)
Да в данном контексте под интерфейсами подразумеваются абстрактные классы, чтобы явно указать в примерах, какие методы должны быть реализованы. Поскольку, согласно документации (
typing.Protocol(an instance ofabc.ABCMeta)) Протокол создан на основе метаклассаABCMeta,как и абстрактный класс, то, имхо, для данного примера это не является критомС точки зрения нейминга согласен с Вами, интерфейсами правильнее будет называть Протоколы
Перепутал местами, спасибо, поправил!