Вариант использования ограниченного контекста в доставке еды

Я практикую DDD с одним из своих проектов, и это мое первое взаимодействие с DDD. У меня есть система, в которой есть 3 разных типа пользователей: один шеф-повар, один доставщик и обычный пользователь. Шеф - это концепт, который может рекламировать свои рецепты и принимать заказы. Delivery-man — это пользователь, который регистрируется и действует только для доставки еды по соответствующим адресам, а обычный пользователь — это тот, кто хочет заказать еду.

Насколько я понимаю, эти три типа пользователей относятся к трем разным ограниченным контекстам, а не к одному, такому как «Управление пользователями» ИЛИ «Управление идентификацией». Может ли кто-нибудь поправить меня, если я ошибаюсь?


object-oriented-analysis domain-driven-design
person Muhammad Sufyian    schedule 24.10.2018    source источник
comment
ИМО, этот вопрос слишком широк и основан на мнениях.   -  person Hooman Bahreini    schedule 25.10.2018

Ответы (1)


arrow_upward
3
arrow_downward

Невозможно сказать без дополнительной информации, но вот некоторые подсказки.

Если вы думаете о «ограниченных контекстах» CRUD, таких как «Пользователи», «Повара», «Доставщики», это почти наверняка будет неправильным. Контексты не являются CRUD-сервисами для "сущности", они представляют собой семантически связную единицу функций.

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

Вот еще один способ подумать об этом: ограниченный контекст должен продолжать работать, даже если другие ограниченные контексты не работают. (Он может медленно устаревать, но будет продолжать работать).

Некоторые идеи ограниченных контекстов:

  • Поиск
  • Заказ
  • Доставка

Search предназначен для просмотра ресторанов/поваров. Обратите внимание, что эта вещь не нуждается ни в каком общении. Данные будут передаваться в него при необходимости, но он будет продолжать работать, даже если Ordering и Delivery не работают.

Ordering содержит некоторые пользовательские данные, такие как платежный адрес, кредитные карты и т. д., но не все. Например, не нужен адрес доставки. Когда заказ будет завершен, он просто перенаправит пользователя на Delivery. Обратите внимание еще раз, это будет работать, даже если Search или Delivery не работает.

Delivery будет иметь адрес доставки пользователя и выбрать курьера, отслеживать доставку. Обратите внимание еще раз: это будет работать, даже если Search или Ordering не работают.

Круто то, что этим троим вообще не понадобится прямое общение. Если бы все они были веб-приложениями, они могли бы просто связать (перенаправить) пользователя на следующий шаг, и пользователь даже не увидел бы, что это потенциально разные приложения.

У этого стиля на самом деле есть название, оно называется Автономные системы.

person Robert Bräutigam    schedule 25.10.2018
comment
Спасибо @Robert за такой подробный ответ, позвольте мне предоставить больше контекста проблемной области, поэтому проект, над которым я работаю, - это служба доставки еды, которая облегчает пользователю возможность поиска поваров, заказ от шеф-повара предложение, шеф-повар принимает/отклоняет заказ, если шеф-повар принимает его, то пользователь, который размещает заказ, может отслеживать процесс доставки еды, как только еда будет готова, доставщик получает уведомление о том, что готов к выдаче по какому-либо адресу, и производится оплата через наличные. - person Muhammad Sufyian; 25.10.2018
comment
Таким образом, на платформе будут зарегистрированы три различных типа актеров: один, который может готовить еду, и мы называем его шеф-поваром, другой, который хочет есть, для них они клиенты, доставщик, который способствует доставке еды в нужное место. человек. Я попал в ловушку, что при разработке услуг для их аутентификации/авторизации он должен попадать в один ограниченный контекст (IdentityManagement) или три разных ограниченных контекста (управление учетными записями клиентов, управление учетными записями шеф-повара, учетная запись доставщика). -управление) . Поскольку все они являются пользователями, но отражают совершенно разные концепции. Спасибо - person Muhammad Sufyian; 25.10.2018
comment
@MuhammadSufyian есть о чем подумать, управление пользователями будет частью вашего решения, однако действительно ли оно является частью аутентификации частью вашей проблемной области? Я пытаюсь сказать, что вам не нужно DDD все вещи! - person Naeem Sarfraz; 29.10.2018
comment
Роберт, я согласен с вашим ответом, но у меня есть сомнения, что служба может выполнять какую-либо значимую работу, когда другие службы не работают. Например, если поиск не работает, заказы не будут приниматься, потому что пользователи ничего не могут найти. Если доставка не работает, заказ не может получать заказы, потому что процесс оформления заказа требует, чтобы служба доставки приняла адрес доставки и подтвердила, что ресторан может доставить по этому адресу. И так далее. Я согласен с тем, что уже запущенные процессы должны иметь возможность выполняться в рамках одной службы, не нуждаясь в других. - person Francesc Castells; 31.10.2018
comment
Подумайте о примерах все еще значимой частичной работы: у пользователя может быть страница отложенного заказа, даже если поиск не работает или доставка задерживается (подумайте о Рождестве: вы можете заказать последний доступный товар по специальному предложению и получить его через неделю). 25-го; в то время как поиск перегружен слишком большим количеством пользователей, желающих получить одно и то же редкое предложение). О процессе оформления заказа @Robert упомянул, что адрес не является проблемой для заказа: мы можем добавить возможность выноса. Имхо, мы обслуживаем не только пользователя с одним идеальным рабочим процессом, а ограниченные контексты DDD помогают выжить в сложных сценариях реального мира. - person Kamafeather; 22.07.2021