Как организовать архитектуру мероприятий?

Question

[Dos]

Хочу построить приложение на независимых сервисах. Но немного теряюсь. Прошу помощи у вас!

Задача
Разработать систему, автоматизирующую календарь соревнований спортивной Федерации и позволяющую собирать заявки на эти соревнования централизованно.

Немного о будущих цифрах:
Организаций: ~ 2000
тренеров: ~ 15000
спортсменов: ~ 25000
Заявок: ~ 100000 в год

Основные характеристики:

1. каждая спортивная школа, входящая в состав Федерации, имеет свой личный кабинет в системе, позволяющий вести данные по своей школе, своим тренерам и учащимся (спортсменам)
   
2. подать заявку может любой желающий имеющий аккаунт в системе
   
3. уполномоченные сотрудники Федерации имеют свой личный кабинет, в котором они добавляют информацию о предстоящих соревнованиях (ведут календарь соревнований), а также контролируют данные, поступающие от спортивных школ
   
4. непосредственные организаторы соревнований имеют возможность актуализировать информацию о соревнованиях в системе, в частности, добавлять положение, категории и другую информацию
   
5. все предварительные заявки от представителей школ поступают организатору для утверждения
   
6. у мероприятия имеются три типа регистрации: соревнования, батлы, мастер-классы. Через время могут добавиться другие типы регистраций
   

Разработка с использованием: Symfony+Vue+Mysql

Хочу понять как спроектировать это всё на независимых сервисах. Как я вижу это?

1. Сервис пользователей
Служит для авторизации на сайте, работе с правами доступа и API
2. Сервис ГЕО (города, регионы, страны)
Служит для хранения всех стран городов (Информационная система)
3. Сервис Мероприятий
Собирает в себе всю информацию касаемо мероприятий: организатор, отзывы, новости, партнёры, контакты и другая информация.
4. Сервис Регистраций
Сервис служит для управления регистрациями до мероприятия и разделяется на типы: соревнования, батлы, мастер-класс.
Нужно ли делить регистрацию на каждый отдельный сервис/библиотеку?
5. Сервис Счёт
Сервис служит для управлением мероприятием на самом событии и подсчёта результатов: соревнований, батлов
Нужно ли делить счёт на каждый отдельный сервис/библиотеку?
6. Сервис Персон
Сервис служит для сбора в одном всех персон: тренеров, спортсменов, организаторов, оргкомитет и др.
7. Сервис Организаций
Сервис служит для сбора в едином аккаунте всех типов организаций

У меня есть несколько вопросов:
1. Правильно ли я мыслю по построению сервисов? Возможно следует сделать один сервис Мероприятия, который будет объединять в себе всё это? Тогда как организовать лучше слабую связанность в сервисе, чтобы можно было менять одну регистрацию на другую? Например, сделали новую регистрацию v2.0 и теперь нужно заменить. Или дописали новую - нужно добавить. Интерфейсы?
2. Имеет ли смысл регистрацию и счёты разделить на свои отдельные сервисы.
3. Имеет ли смысл делать общий сервис Person? Или в каждом сервисе добавить Member, Teacher, Artist Organizator?

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

Благодарю за помощь! Выслушаю все варианты!

Comments

[Антон Р.]

А кто эту схему рисовал? Ты не Характеристики нам описывай а сам функционал системы, зачем это надо и как всё происходит, описывай методы, говоря языком ООП программирования. Сейчас нихрена не понятно.

[Владимир Коротенко]

Сделайте монолит. Не стоит делать микросервисы потому что это модно.
Балансировку делайте по региональному признаку.
1. WFE для главной страницы, там же регистрация и прочее.
2. WFE для региона, 1 WFE может обслуживать несколько регионов через домены 3 уровня.
3. BLS бизнес логика и апи.
4. Сервер БД и его реплика в горячем резерве.
5. WBE - сугубо админский сайт для внутренней кухни.

Answer 1

[Евгений Ромашкан]

Немного о будущих цифрах:
Организаций: ~ 2000
тренеров: ~ 15000
спортсменов: ~ 25000
Заявок: ~ 100000 в год

С нагрузками проблем не будет, не беспокойтесь.

Возможно следует сделать один сервис Мероприятия, который будет объединять в себе всё это?

Да. Микросервисы про независимую разработку разными командами и независимый деплой.
Для разработки приложения в одиночку они не нужны совсем. Это огромное усложнение впустую.

Тогда как организовать лучше слабую связанность в сервисе, чтобы можно было менять одну регистрацию на другую?

Внутри монолита приложение так же прекрасно разбивается на модули/контексты, как и в микросервисах.

Например, сделали новую регистрацию v2.0 и теперь нужно заменить. Или дописали новую - нужно добавить. Интерфейсы?

Да, интерфейсы, IoC, контроль зависимостей, декомпозиция, итеративное проектирование и рефакторинг.

Имеет ли смысл регистрацию и счёты разделить на свои отдельные сервисы.

Имеет смысл ложить вместе те данные, которые вместе меняются и используются. Постарайтесь ответить для себя на этот вопрос. Так же помните что лучший выбор решения - не выбирать а отложить на потом.

3. Имеет ли смысл делать общий сервис Person? Или в каждом сервисе добавить Member, Teacher, Artist Organizator?

Сквозной функционал между сервисами это плохо т.к. плодит зависимости и влечёт каскадные изменения после каждой правки. Делаете сервисы так чтобы им не было важно, Teacher там, Member или Artist.

От монолита точно стоит уходить.

Нет.

p.s. Хотите использовать что-то крутое и сделать ваш проект лучше и качественнее - пишите unit-тесты.

Comments

[Dos]

Внутри монолита приложение так же прекрасно разбивается на модули/контексты, как и в микросервисах.

Теперь понял, что монолит пока что не плохо. Согласен с этим. Буду просто разбивать по папкам. src/Usersrc/Event Либо так:

Event // Модуль-сервис мероприятий
            Entity сущности
                Disciplines //Дисциплины
                Events // мероприятия
                    Event
                    Registrations //регистрации
                        Competition//на соревнования
                        Battle//на батлы
                Geo /гео
                Organizations /организации
                Persons /персоны

У меня возникает такая ситуация. Как отделить регистрацию от мероприятия? Пока что она принимает объект Event. Использовать интерфейс EventInterface и его реализовать? Пока не могу сообразить как это можно сделать всё слабо связанным. Чтобы заменить или если будет интересно другим - подключаем эту библиотеку другим.

Сквозной функционал между сервисами это плохо т.к. плодит зависимости и влечёт каскадные изменения после каждой правки. Делаете сервисы так чтобы им не было важно, Teacher там, Member или Artist.

Вот это я и хочу, но что вы понимаете под этой абстракцией? Не могу понять как сделать лучше. Интерфейсами?

p.s. Хотите использовать что-то крутое и сделать ваш проект лучше и качественнее - пишите unit-тесты.

КОнечно! Без Unit тестов не начну) Функциональные делаю меньше, а юниты на старте 60-70% покрытия.

[Евгений Ромашкан]

У меня возникает такая ситуация. Как отделить регистрацию от мероприятия? Пока что она принимает объект Event. Использовать интерфейс EventInterface и его реализовать?

Event - просто DTO - если зависеть только от него и в одном месте - проблем не будет. Будет какой-то слой что зависит от ивентов и преобразует их в какие-то команды в рамках текущего контекста. Если смените общение на http - перепишете этот слой, чтобы зависел не от DTO ивента а от, условно. запроса в HTTP.

Сквозной функционал между сервисами это плохо т.к. плодит зависимости и влечёт каскадные изменения после каждой правки. Делаете сервисы так чтобы им не было важно, Teacher там, Member или Artist.

Вот это я и хочу, но что вы понимаете под этой абстракцией? Не могу понять как сделать лучше. Интерфейсами?

Нужно делать так, чтобы другим сервисам не важно было кто перед ними - зачем, например, в контесте "Счёт" знать должность человека и какие бывают должности?

[Dos]

Евгений Ромашкан, понял)