Как правильно построить сервисную архитектуру?

Обсуждаем, как правильно строить приложения
Ответить
myks1992@mail.ru
Сообщения: 147
Зарегистрирован: 2017.11.15, 23:54

Как правильно построить сервисную архитектуру?

Сообщение myks1992@mail.ru »

Всем привет! Нужна помощь по архитектуре кода и базы.

Есть сервис мероприятий, у которого следующие задачи:

1. Отображать информацию (дата начала, город, положение...) о мероприятиях разного типа: конкурсы, мастер-классы, фестивали, чемпионаты и так далее.
2. Уведомлять подписчиков о новостях.
3. Собирать отзывы.
4. Регистрировать участников на мероприятие

Так как все пункты могут переиспользоваться в других проектах, то хотел бы их разделить на отдельные пакеты (библиотеки). Но пока не очень представляется как это сделать. Пока что вижу это так:
  • vmc-event //библиотека, которая собирает в себе все библиотеки и выводит общую информацию
  • vmc-event-notify //библиотека уведомлений
  • vmc-event-news // библиотека новостей
  • vmc-registration //библиотека регистрации

Библиотека регистрации вообще может сильно меняться в зависимости от типа мероприятия. Поэтому полагаю, что этот покет надо разбить сильнее:
  • vmc-event-registration //ядро, где собирается общая функциональность (участники, калькуляторы цен...). В дальнейшем, поможет на базе ядра быстро создавать новый тип регистрации, которого ещё нет.
  • vmc-event-registration-competition //регистрация соревнований
  • vmc-event-registration-masterclass //регистрация мастер-классов
  • vmc-event-registration-battle //регистрация на батлы

Основная проблема по архитектуре кода и базы именно регистрации. Правильно ли я мыслю по поводу разделения регистрации на пакеты. Функциональность регистрации иногда отличается сильно между типами, а иногда нет. При регистрации на мероприятие типа соревнования нужно проверять членство, расчет цены участия сложны. В то время как на батл нужно просто ник и номинация.

Подскажите как реализовать подобную задачу?
Либо вообще не париться и разделять всё по папкам сервиса Мероприятий?
Полагаю, что в базе данных регистрации будет храниться только id мероприятия пакета vmc-event и все операции связывать с id этого мероприятия. Правильно ли я мыслю?

Буду очень благодарен за помощь! Если требуется пояснение или подробное описание какой-то части - напишите вопросы. Опишу подробно. Задача глобальная, поэтому описать все детали сложно и не нужно. Такой вопрос никто не прочитает)
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Как правильно построить сервисную архитектуру?

Сообщение ElisDN »

Не заморачивайтесь библиотеками. Сделайте пока нативно с примерным разделением по папкам. Потренируетесь и со временем оптимальную структуру найдёте.

Понадобится в других проектах – скопипастите туда нужную папку. В библиотеки имеет смысл выносить мелкие инструменты. Целиковые же разделы сайта выносить смысла мало, так как в других проектах наверняка потребуется что-то переделывать.
myks1992@mail.ru
Сообщения: 147
Зарегистрирован: 2017.11.15, 23:54

Re: Как правильно построить сервисную архитектуру?

Сообщение myks1992@mail.ru »

ElisDN писал(а): 2019.10.14, 22:55 Не заморачивайтесь библиотеками. Сделайте пока нативно с примерным разделением по папкам. Потренируетесь и со временем оптимальную структуру найдёте.

Понадобится в других проектах – скопипастите туда нужную папку. В библиотеки имеет смысл выносить мелкие инструменты. Целиковые же разделы сайта выносить смысла мало, так как в других проектах наверняка потребуется что-то переделывать.
Как всегда помогаете!)

Можете ещё подсказать с регистрацией? Она достаточно функциональная. И она точно будет подключаться в двух проектах. Её уже на этапе создания желательно выделить в свой пакет из-за своей сложности. И в этом пакете делить по папкам типы регистраций в зависимости от типа регистрации. И у меня стоит такой вопрос. Регистрация будет отдельным сервисом (модуль, бандл) или же это подключаемая библиотека?

Чем они для меня отличаются?

1. Модуль. Исходя из вашей статьи про независимые модули, то этот модуль должен иметь в себе всё, что ему нужно для его работы. В моем случае для работы регистрации требуются данные по мероприятию (название, дата, город) и данные по людям и организациям, которые тоже используются в других частях. Обьединить это нет смысла, так как там много лишнего для других частей. Да и не понятно что главнее — мероприятия или организации. Поэтому было принято регенте отделить.

Правильно ли я понимаю, что в сервисе регистрации нужно создать свои мероприятия, организации и уже с сервисом мероприятий и организаций обмениваться сообщениями и синхронизировать их?

Или же

2. Создать библиотеку, которая не может существовать без сервиса мероприятий. Регистрация будет использовать интерфейс мероприятия, который необходимо определить через DI контейнер. Затем повесить ключи в базе данных таблиц и установить связи.

Вообще хочется сделать второй вариант, но это, подозреваю, не совсем правильно. Если делать по вашим независимым модулям, то это первый вариант.

Если брать простую реализацию одного проекта, то сложного тут особо нет ничего. Но когда включается поддержка версий этой регистрации, а так же переиспользуемость и развитие пакета, то вводит немного в ступор. Раньше не работал с пакетами и не очень представляю как лучше организовать этот в пакет. Опять много вопросов) А дальше предстоит счетная система зарегистрированных...

Как здесь лучше поступить, если при этом важна переиспользуемость регистрации в других проектах на старте?

Благодарю!)
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Как правильно построить сервисную архитектуру?

Сообщение anton_z »

myks1992@mail.ru писал(а): 2019.10.15, 02:27
Как здесь лучше поступить, если при этом важна переиспользуемость регистрации в других проектах на старте?
Вам же уже объяснили. Не заморачивайтесь с делением на модули на старте проекта, все равно будете потом переделывать. Сейчас на это потратите лишнее время, сроки можете затянуть. Не рискуйте. Сделайте один проект, потом, когда начнете второй делать, тогда реально поймете, что общего, и что можно вынести, и вообще возможно ли это и насколько оправдано. Предметная область нетиповая, поэтому сделать хорошее разделение до реализации не получится, так как нет примеров/опыта. Необходимый опыт для разделения приобретете после написания первого проекта, в процессе или после (но никак не ДО) написания второго.

P.S. Погуглите premature generalization.
myks1992@mail.ru
Сообщения: 147
Зарегистрирован: 2017.11.15, 23:54

Re: Как правильно построить сервисную архитектуру?

Сообщение myks1992@mail.ru »

anton_z писал(а): 2019.10.15, 03:10
myks1992@mail.ru писал(а): 2019.10.15, 02:27
Как здесь лучше поступить, если при этом важна переиспользуемость регистрации в других проектах на старте?
Вам же уже объяснили. Не заморачивайтесь с делением на модули на старте проекта, все равно будете потом переделывать. Сейчас на это потратите лишнее время, сроки можете затянуть. Не рискуйте. Сделайте один проект, потом, когда начнете второй делать, тогда реально поймете, что общего, и что можно вынести, и вообще возможно ли это и насколько оправдано. Предметная область нетиповая, поэтому сделать хорошее разделение до реализации не получится, так как нет примеров/опыта. Необходимый опыт для разделения приобретете после написания первого проекта, в процессе написания второго.

Погуглите premature generalization.
Понял) Может действительно решение придёт с окончательной реализацией. Частично это уже написано. Поэтому вопрос и возник на этапе построения новых регистраций и подключения к другому проекту.
Ответить