Вникаю сильно в DDD. Вопрос связан с межагрегатными связями. Первое правило Межагрегатных связей заключается в том, что агрегаты всегда ссылаются друг на друга через уникальный идентификатор (например, первичный ключ) вместо прямых ссылок на объекты. Это понятно, но как быть, если мы пошли немного иначе?
Например, есть Мероприятия. У мероприятия есть участники. В Контексте участников мы создаем Member. ID Генерируется используя UUID. Проходит какое-то время, создается новый функционал. Теперь участникам можно использовать личные кабинеты. Они регистрируются в контексте Auth. Там у них тоже генерируется этот ID. Отлично. Но как теперь нам связать эти два контекста. Исходя из логики нам нужно у Memer (участника мероприятия) заменить ID на тот, который был сгенерирован в Auth. Я бы мог поступить следующим образом:
1. В Member добавляем метод changeId(Id $id)
2. Получаем ID из Auth и с помощью метода changeId(Id $id) привязываем к аккаунту. Теперь каждый Member может иметь доступ к своему аккаунту.
Вроде бы всё просто, но у меня возникает вопрос о правильности. Ведь DDD это понятный язык, а метод changeId() не особо понятно. Да и вообще этот метод какой-то лишний. Другое дело если пользователь сам заходит в Event и регистрируется как участник. В таком случае мы можем легко иметь связь без всяких дополнительных методов. Просто присваивая ID из Auth. Но как идти от обратного?) Подскажите, пожалуйста) Вопрос, наверное, простой, но хочу делать правильно!
Dmitry, приветствую!
В реальном мире есть некий человек, которого в программной системе вы должны как-то смоделировать в виде какого-то класса, т.е. сущности предметной области. Ваша предметная область в программной системе разбита на ограниченные контексты: Мероприятия и Авторизация. Так вот, в Мероприятии у вас должен быть класс Member, а в Авторизации класс User, где идентификаторы обоих классов всегда равны, если они представляют одного и того же человека в реальном мире. Поэтому вышеописанное вами решение в корне неверно.
1. Участника может добавить представитель. То есть у него может и не быть аккаунта изначально. При и этом из уникальных данных: фио, дата рождения, пол, город. Остальные данные не заполняются. Но в процессе этот участник захочет привязать свою историю к Аккаунту. Как быть?
2. Этот участник может и существовать в других ограниченных контекстах. Как мне потом их связать? Например, он был добавлен как сотрудник в контексте Склад. Затем как участник в контексте Мероприятия, а потом он захотел создать единый аккаунт на два контекста. Как мне их связать? Я вижу только дополнительную связующую таблицу. Больше не понимаю как можно сделать. Либо выделить Person в отдельный контекст и как-то пытаться его делать уникальным. Только опять же как.
В целом вопросов много. Как быть с этим не понимаю. Любой другой домен знаю как сделать, а вот свой вообще не могу. Хоть убей. Запара.
Аутенцикация - служит для аутенцикации пользователей, восстановление пароля. Афиша- служит для публикации различных типов мероприятий разного типа: соревнования, лагеря, батлы, конкурсы, чемпионаты и так далее. Регистрация - служит управления заявками на мероприятия разного типа, расчёта стоимости участия, подсчета наград, составления расписания. Результаты - служит для подсчета результатов разного типа. Гео - служит для хранения информации о городах странах и регионах.
В мероприятиях он: Организатор, волонтёр, охранник, ведущий.
В регистрации он: участник, наставник
В результатах он: участник, судья, ведущий, наставник
1. Участника может добавить представитель. То есть у него может и не быть аккаунта изначально. При и этом из уникальных данных: фио, дата рождения, пол, город. Остальные данные не заполняются. Но в процессе этот участник захочет привязать свою историю к Аккаунту. Как быть?
Я бы попробовал так: при регистрации участника (Member) в контексте МЕРОПРИЯТИЯ, публикуем так называемые доменные события, а именно Участник_Зарегистрирован (MemberRegistered). Далее при обработке этого события в контексте ПОЛЬЗОВАТЕЛИ создаем пользователя (User), но пока ещё не активированного. Если участнику потребуется доступ к личному кабинету, то он активирует свою учетную запись по email или номеру телефона.
Вот и я о том же) а как тогда поступить, если участников сначала регистрирует руководитель. Но с ростом системы всем участникам можно зарегистрировать личные кабинеты. При том что аккаунт один на все сервисы.
То есть картина получается такая:
1. У участника может уже быть аккаунт при использовании других сервисов.
2. Участника может зарегистрировать руководитель.
Как нам это связать?)
А ещё круче, когда этот участник потом может стать руководителем. И их тоже надо связать в другом контексте. А ещё через время может быть организатором.
Dmitry, что-то вы усложняете. Делайте регистрацию пользователя с определенной ролью. В зависимости от роли открывайте функционал (создание других, личный кабинет итд). Не должен новый функционал менять идентификатор пользователя.
Илья, я не усложняю. Реальная картина. Участников могут зарегистрировать руководители, даже когда у них нет аккаунта. Аккаунт когда-то могут создать сами участники. В один момент времени у нас появляется возможность всем участникам выдать личные кабинеты. Как теперь это связать при условии что ID. Менять нельзя.
Dmitry, ввести роль Руководитель назначить эту роль для аккаунтов руководителей. Ввести роль Участник. Преобразовать участников в аккаунты с использованием с сохранением Id участника. Назначить роли для участников. Научить приложение работать с ролями.
Илья, хорошо. У меня сервисы:
1. Мероприятия
2. Аутенфикация
Что я делаю? Объединяю участников, руководителей, организаторов в одной сущности Аккаунт и разделяю их по ролям. Это понятно.
В аутенфикации есть сущность User. Аутенфикация выполняет роль: регистрации, аутенфикации, восстановление пароля и т д
Как происходит процесс?
Организатор создаёт событие и открывает регистрацию. В открытую регистрацию могут регистрироваться участники или участников может зарегистрировать руководитель. Допустим участников на мероприятие регистрирует руководитель. Если они зарегистрированы в аккаунте, то он просо выбирает участников. Если нет, то создаёт аккаунт в контексте Мероприятия.
Проходит какое-то время и участнику хочется следить за своей карьерой из личного кабинета. Он регистрируется в контексте Аутеныикация. Но как ему связать свой User с Account?
Dmitry, я не очень понимаю почему у вас 2 отдельные сущности user и аккаунт. Как пользователь входит в мероприятие если он не зарегистрирован? Как происходит аутентификация?
Account это вы посоветовали объединить все роли в одном аккаунте в контексте Мероприятия.
User - это единый аккаунт аутенфикаци.
Аккаунт не всегда = User.
Я же говорю, что на мероприятие регистрируется группа участников (танцевальный номер). Естественно это. Танцевальный номер регистрируется представителем. В моём случае это Руководитель. То есть есть мероприятие. На него можно зарегистрировать танцевальный номер из 25 человек (участников). Руководитель заходит в регистрацию. Заполняет необходимые данные. Добавляет участников выбирая из из списка или создаёт новых. В этот момент идёт расхождение Account и User. То есть чтобы зарегистрировать на мероприятие всех участников группы им в момент регистрации не нужен User. Но вот они участвуют один раз, 2, 12... И теперь каждый участник хочет следить за своими успехами. Для этого он регистрируется в User и запрашивает доступ к своему Account в мероприятиях. Как мне в итоге связать это все? При том, что на все контексты должен быть единый аккаунт.
Илья, руководитель в личном кабинете организации может привязать user к участнику. Или по запросу к руководителям проекта. Можно ещё по email, например.
Илья, вот и я так думал. Но будет ли это правильно? Наверное, в моем случае иначе никак... на этом очень сильно завис.
Правильно ли я понимаю:
Всех пользователей контекста Event мы именуем как Member или Account. Но наверное, лучше Member по смыслу для Events. Либо Person. Как правильно?
Либо же лучше отделять сущности
- участники(вокалист, танцор, спортсмен),
- наставники (преподаватель, хореограф, тренер, педагог, судья) ,
- оргкомитет (организатор, волонтёр, ведущий, охрана, счётчик)?
Участники регистрируются сами или руководителем или счетчиком/организатором.
Тренера добавляются сами, либо счетчиком:организатором.
Средний
Простой
Простой
