Как ослуществляется выборка данный в модульной или микросервисной архитектуре?
Всем привет. Озадачился вопросом реализации модульного монолита и возник следующий вопрос:
Допустим у нас есть некоторое e-commerce система. Она имеет несколько модулей, к примеру модуль магазина, который содержит данные о заказах и товарах, и модуль платежей. Далее перед нами стоит задача вывести заказы 30 заказов на странице, которые имеет статус X, и которые оплачены платёжной системой Y при условии, что заказов и платежей может быть очень большое число.
Если у нас монолит, то данная задача решается простейшим SQL запросом с лимитом, однако если у нас есть модульность, то вот тут у меня и возникает вопрос. Т.к. мы не можем сделать выборку всех заказов в статусе X, т.к. их очень много, но мы и не можем сделать выборку с лимитом т.к. не знаем точно, что данные заказы будут оплачены платёжной системой Y и наоборот, если будем строить выборку от оплат. В общем получается, что мы решаем вопросы, которые легко решены в БД, но мы их пытаемся решить в коде. Как поступать то?
Т.к. мы не можем сделать выборку всех заказов в статусе X, т.к. их очень много, но мы и не можем сделать выборку с лимитом т.к. не знаем точно, что данные заказы будут оплачены платёжной системой Y и наоборот, если будем строить выборку от оплат. В общем получается, что мы решаем вопросы, которые легко решены в БД, но мы их пытаемся решить в коде. Как поступать то?
Это типичная проблема которая возникает после распила монолита на части. Если раньше
монолит ходил в базу и делал любые SQL, то после разделения отвественностей уже такие
игры не работают.
Вы говорите что не знаете точно какие заказы оплачены. Вам нужно создать новый метод
который в правильном сервисе выдает только оплаченные заказы. А в базу ходить не надо.
Она вообще может быть недоступная по инфо-безопасности для прочих модулей.
Вот и есть правильная микросвервисная архитектура.
Решение же зависит от того какое у вас там разделение. А до этого и возникает основная проблема, вы прекрасно понимаете как работает монолит, но вдруг внезапно решили переделать на микросервисы. Но это так не работает, на микросервисы надо переделывать, когда вы реально уперлись в какое-то ограничение монолита, вот тогда и будет понимание, что именно вы хотите выносить, и обычно это происходит поэтапно, сначала одну часть, потом другую и т.п. Либо изначально есть архитектор с опытом в микросервисах, который сразу правильно разобьет всё на них.
Хорошо, я разрабатываю магазин, хочу заранее красиво организовать код, мне нравится идея разделение проекта на логические части, чтобы не сваливать весь код в одну кучу, что вот у тебя 30 ORM моделей, вот у тебя десятки классов из сервисного слоя, которые организуют бизнес-логику. Ты разделяешь проект на логические части, которые назовем модулями, далее, чтобы код не был сильно связан между модулями, ты условно можешь разделить логически (не на уровни языка программирования) какие-то части на те, которые могут быть как бы "публичными" для остальных участников системы и "приватными". И теперь разработчики могут программировать отдельно друг от друга, разрабатывая свои модули, и взаимодействуя через публичные интерфейсы других модулей.
Такой подход красиво звучит до тех пор, пока мы не приходим к месту, когда нам надо собрать какой-то чуть более сложный набор данных из разных модулей и вся красота рушится этим фактом. Поэтому я и задался вопросом, а как решить эту проблему?
DYLAN, так может надо просто оставить монолит? ой да, еще забыл, микросервисы это еще и общая шина данных, она у тебя есть? если подойти с понимания ее работы, то можно облегчить себе задачу
Модуль платежей - занимается платежами (как подсказывает капитан Очевидность), никаким хранением данных он заниматься не должен (логи разве что вести). Если речь о микросервисной структуре, то после платежа информация о нем рассылается через вебхуки всем подписчикам т.е. магазину и, например, какому-то бух.модулю
Сложный
Средний
Простой
