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

Question

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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