Хорошая практика обработки варианта использования, требующего данных из другого ограниченного контекста.

Мое программное обеспечение — это своего рода социальная сеть, участники которой могут, помимо прочего, планировать некоторые встречи между собой.

Я решил выделить эти три ограниченных контекста (DDD):

  • IdentityAndAccessContext, в основном связанный с аутентификацией/авторизацией пользователя.
  • SocialContext, касающийся Участников и всей социальной информации о них; свои интересы и т. д., как классическая социальная сеть.
  • MeetingsContext, относящийся к встречам между некоторыми участниками. Мы говорим о переведенных Объектах Ценности как Создателях/Посетителях/Участниках и т. д.

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

Как вы уже могли догадаться, SocialContext, несомненно, является основным источником данных об участниках в социальном плане.

Должен ли я создать своего рода Открытую службу хоста в SocialContext, возвращающую некоторые важные данные участников для варианта использования?

Он будет использоваться MeetingsContext напрямую (протокол REST), возможно, при необходимости через уровень защиты от коррупции.

Или лучше кэшировать или даже дублировать данные соответствующих участников в MeetingsContext, чтобы улучшить его автономный аспект?

При использовании решения для кэширования кеш будет синхронизироваться с обеспечением согласованности в конечном итоге.

Что является хорошей практикой в ​​этом случае?


architecture rest domain-driven-design bounded-contexts
person Mik378    schedule 04.09.2017    source источник
comment
fwiw, IdentityAndAccessContext вообще не является ограниченным контекстом или доменной концепцией. Идентификация и доступ (авторизация, аутентификация, ACL и т. д.) являются проблемами приложения, а не проблемы домена, которые должны обрабатываться на уровне приложения, а не на уровне домена.   -  person Tseng    schedule 05.09.2017
comment
@Tseng Прочтите книгу Вона Вернона «Реализация дизайна, управляемого предметной областью». Вы увидите, что IdentityAndAccessContext — это ограниченный контекст, который он берет с собой.   -  person Mik378    schedule 05.09.2017
comment
Аутентификация (=Идентификация) почти никогда не является частью домена и, следовательно, не является бизнес-логикой (если только ваш домен не является какой-либо охранной компанией, которая управляет безопасным доступом для других компаний, т.е. создает и выдает физические токены сотрудникам некоторых компаний). Аутентификация/идентификация обычно не играют роли в бизнес-процессе, и это хорошо, поскольку аутентификация и идентификация могут меняться в зависимости от вашей инфраструктуры. Это как АНБ. Ваша личность проверяется только на воротах (приложение). Как только вы окажетесь внутри (домена), вы можете свободно ходить со своей именной табличкой (идентификатором пользователя)   -  person Tseng    schedule 05.09.2017
comment
В этом контексте вам нужна идентификация только для того, чтобы подтвердить, что вошедший в систему пользователь является пользователем из SocialContext с идентификатором xyz, и за это явно отвечает приложение, а не не домен.   -  person Tseng    schedule 05.09.2017
comment
@Tseng Вы можете заблокировать одного человека, вы можете создать учетную запись от имени другого человека, вы можете изменить определенные роли одного или нескольких человек, например, в зависимости от количества подключений в месяц и т. д. Контекст I&A определенно может иметь свой собственный домен со своей сложностью.   -  person Mik378    schedule 06.09.2017
comment
Вы смешиваете человека с личностью / учетными записями здесь. В вашем SocialContext Person или Emplyoee находятся сущности/агрегаты домена. Вы не можете заблокировать сотрудника, это нигде не является частью бизнес-процесса. Вы можете просто назначить (группе/арендатору/компании/и т. д.)/удалить/удалить его. Идентичность — это совсем другое. Личность (в простейшем случае) может состоять только из имени пользователя, логина и связанного с ним идентификатора (т. е. идентификатора человека), поэтому вы можете сказать: он/она подтвердил, что он/она является этим человеком. Ничего лишнего, никакой бизнес-логики, все дело в приложении.   -  person Tseng    schedule 06.09.2017
comment
@Tseng Да, да, это было просто, чтобы объяснить мою точку зрения. Настоящий термин - Пользователь, извините.   -  person Mik378    schedule 06.09.2017
comment
Но вход в систему, проверка пароля, сброс пароля, изменение имени пользователя (это никак не влияет на сущности Person или Emplyoee) и т. д. Все это не бизнес-процессы, следовательно: не доменная логика. Все они довольно специфичны для приложения.   -  person Tseng    schedule 06.09.2017
comment
@Tseng Как бы вы объяснили, что Вон Вернон считает это BC?   -  person Mik378    schedule 06.09.2017
comment
github.com/VaughnVernon/IDDD_Samples/ дерево/мастер/   -  person Mik378    schedule 06.09.2017
comment
Очевидно (из репозитория github), он перепутал Person и User в одном контексте, и только он может сказать, почему. Упрощение для книги/примера? Person или Employee подходят в качестве объекта домена, поскольку они описывают объект, являющийся частью бизнес-процесса. User на самом деле нет. Лично я бы убрал из него User*, AuthenticationService и PasswordService, а также аутентификацию.   -  person Tseng    schedule 06.09.2017
comment
Домен может просто иметь Someinterface.canAccess(personId, "someClaimOrPermission"), и приложение может реализовать этот интерфейс с помощью этого метода. Таким образом, домен не будет знать о таких понятиях, как утверждения. Роли могут быть приемлемыми, в зависимости от проблемной области (т. е. роли распространены в бизнес-процессах, например, менеджер, служба поддержки и т. д.). Но в деталях реализации (на прикладном уровне) роль может быть представлена ​​как набор требований. Домену не нужно знать об этой детали инфраструктуры   -  person Tseng    schedule 06.09.2017
comment
Нет, явно ничего не смешивает. Человек — это своего рода профиль пользователя (основные данные, такие как имя), но он не знает о проблемах бизнес-домена.   -  person Mik378    schedule 06.09.2017
comment
Я согласен, поэтому я использую некоторые шлюзы для работы с контекстом I&A из других контекстов, таких как ваш canAccess. Но я искренне верю, что I&A — это бизнес-компания.   -  person Mik378    schedule 06.09.2017
comment
Прочтите книгу IDDD, вы увидите, что она достаточно подробная и не простая для примера в книге.   -  person Mik378    schedule 06.09.2017
comment
Что ж, это ваше мнение, и я вряд ли его изменю, просто предложил свою точку зрения. Последнее, что нужно написать (это становится долго): вы должны подумать об этом (а не догматически о том, что написано в книге): В каком четко определенном (реальном мире) доменном контексте вы когда-либо слышали термины имя пользователя и пароль? Я не слышал. Они не являются частью бизнес-процесса. Бизнес-процесс часто является тем, как работает бизнес, даже если у них нет программного обеспечения, но оно помогает им в их процессе, и термины «пользователь» и «пароль» никогда не появляются там, у вас просто есть люди / сотрудники :)   -  person Tseng    schedule 06.09.2017
comment
Ограниченный контекст — это не просто изоляция вещей, относящихся к сфере бизнеса. Речь идет о сохранении вездесущего языка. Я никогда не слышал об имени пользователя/пароле в бизнес-домене; это просто вопрос технических вещей. Но чтобы сохранить вездесущий язык и поскольку он может иметь сложные правила аутентификации/авторизации, его следует моделировать как отдельный BC. См. нижнюю часть этого ответа: stackoverflow.com/a/23485141/985949   -  person Mik378    schedule 06.09.2017

Ответы (2)


arrow_upward
1
arrow_downward

Композитный пользовательский интерфейс — хороший выбор в таких ситуациях. Контексты вашей встречи не должны знать ничего, кроме идентификатора участника и, возможно, некоторой информации об их предпочтениях в общении, чтобы организовать встречу.

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

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

Вот некоторые ссылки:

person Alexey Zimarev    schedule 04.09.2017
comment
Мне нравится ваша идея о работе только с memberId в контексте встреч. Что касается создателя собрания, который является обязательным для любого собрания, считаете ли вы целесообразным дублировать данные его имени и фамилии (легкие данные) из socialContext, чтобы основной запрос собрания мог быть таким же простым, как выбор * из собраний? Что касается участников, это может привести к приемлемой задержке загрузки, поэтому возможен дополнительный запрос к социальному контексту из пользовательского интерфейса. - person Mik378; 04.09.2017
comment
Конечно, вы можете столкнуться с дублированием данных, особенно если вас не интересуют обновления. В вашем случае это кажется разумным. Я обновил свой ответ ссылкой на некоторые статьи, в которых обсуждается этот подход. - person Alexey Zimarev; 04.09.2017
comment
Спасибо за ссылки Алексей, очень полезно :) - person Mik378; 04.09.2017

arrow_upward
1
arrow_downward

Это зависит от того, но я бы использовал уровень защиты от коррупции (ACL), чтобы разделить три ограниченных контекста.

Что касается использования кеша: вы можете использовать его; это ортогонально ACL. ACL может быть украшен кешем для ускорения работы или может быть локальным хранилищем, которое хранит локальную копию удаленных данных.

Что касается возможной согласованности: конечно, у вас будет возможная согласованность между ограниченными контекстами, ваш дизайн должен учитывать это.

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

Пользовательский интерфейс может быть особым случаем, объединяющим данные из более ограниченных контекстов; не позволяйте пользовательскому интерфейсу стирать четкое разделение между ограниченными контекстами.

person Constantin Galbenu    schedule 04.09.2017
comment
Вы сказали: не позволяйте пользовательскому интерфейсу стирать четкое разделение между ограниченными контекстами. Не могли бы вы перефразировать это предложение, чтобы убедиться, что я ясно уловил вашу мысль? - person Mik378; 04.09.2017
comment
По моему опыту, при создании пользовательского интерфейса для создания определенного представления используется более одного ограниченного контекста, и в этой точке модели имеют тенденцию влиять друг на друга. Пользовательский интерфейс ведет себя как уровень защиты от коррупции, который переводит модели из программного обеспечения в модели из реального мира. - person Constantin Galbenu; 04.09.2017
comment
Пользовательский интерфейс @ConstantinGalbenu может быть самостоятельным контекстом. В большинстве случаев это не ACL. Это может быть шлюз, агрегатор или каждый BC может предоставлять свой собственный пользовательский интерфейс. - person Alexey Zimarev; 04.09.2017
comment
Спасибо @ConstantinGalbenu за ваш ответ, очень ясно. - person Mik378; 04.09.2017