Нет, обычно клиентами управляет один сервис на уровне компании, исключение если только у вас клиенты различаются, что вряд ли, обычно есть одна MDM для клиентов. А вот управление операциями и товарами зависит уже от процессов, вернее от их различия.
Я предпочитаю разбивать по бизнес правилам. На пример финтеха. Есть домен переводы, он огромен и собрать в один сервис (про микро тут даже нет смысла говорить) будет ошибкой конечно. Я разбиваю на мелкие под домены Card2Card, Account2Account, Платежи по начислениям, переводы по номеру телефона (СПБ). У каждого свой процесс, свои правила, своя БД. У вас клиенты (я бы наверное сформулировал как "управление клиентами") это отдельный сервис, управление товарами отдельно, услуги отдельно (и тут возможно даже более мелкое деление в зависимости от процессов надо смотреть)
Добрый день. Безусловно хранение данных в разных схемах одно БД сильно увеличит связанность микросервисов, я бы конечно не рекомендовал так делать. Но всегда есть исключения, иногда просто нет возможности разнести БД как временный вариант, для дальнейшего разделения вполне.
Я с вами практически полностью согласен (к сожаления не смог вас идентифицировать). И действительно "Главный вопрос современности, не как удушить ваш монолит, а в каком случае вам вообще стоит использовать микросервисы и для чего они нужны ", но данная статья ни в коем случае не была направлена на выбор архитектур, да и рассчитана немного на другую аудиторию, на тех молодых специалистов кому (бородатые дядьки) сказали "делаем MSA", и тут зачастую начинается изобретение велосипеда.
А по поводу выбора архитектуры, особенно MSA, на эту тему надо делать отдельную статью, но размещать ее надо будет в разделе "Философия" т.к. тут сколько люде, столько и мнений. Я сам считаю, что к выбору MSA надо подходить крайне осторожно и продуманно, т.к. недостатков и сложностей у этой архитектуры очень много. Скажу больше, лично я считаю, что часть того, что принято считать достоинствами MSA, является ее недостатками. :-) И зачастую переход на микросервисы продиктован "модой", а не реальной необходимостью.
Но повторюсь это отдельная тема. И нам все равно не никуда не деться от микросервисов (по крайней мере в ближайшем будущем) и значит нужно уметь их проектировать и понимать как они работают.
Если вы считаете, что нужно держать изменяемые данные вместе, то ваш путь - монолит. В MSA так не работает, держать все данные в одном месте нонсенс, например, я не смогу при проведении банковского платежа (одна бизнес операция) смешать все в кучу, уменьшение лимитов, расчет комиссии, хранение истории. И т.к. это разные сервисы, то сразу возникает распределенная транзакция и проблема согласованности данных. А как ее решать, сага или не сага, тут уж каждый решает сам, не нравится сага, придумываем свое решие, и возможно потом появится новый потерн.
Нет, обычно клиентами управляет один сервис на уровне компании, исключение если только у вас клиенты различаются, что вряд ли, обычно есть одна MDM для клиентов. А вот управление операциями и товарами зависит уже от процессов, вернее от их различия.
Я предпочитаю разбивать по бизнес правилам. На пример финтеха. Есть домен переводы, он огромен и собрать в один сервис (про микро тут даже нет смысла говорить) будет ошибкой конечно. Я разбиваю на мелкие под домены Card2Card, Account2Account, Платежи по начислениям, переводы по номеру телефона (СПБ). У каждого свой процесс, свои правила, своя БД. У вас клиенты (я бы наверное сформулировал как "управление клиентами") это отдельный сервис, управление товарами отдельно, услуги отдельно (и тут возможно даже более мелкое деление в зависимости от процессов надо смотреть)
Добрый день. Безусловно хранение данных в разных схемах одно БД сильно увеличит связанность микросервисов, я бы конечно не рекомендовал так делать. Но всегда есть исключения, иногда просто нет возможности разнести БД как временный вариант, для дальнейшего разделения вполне.
Я с вами практически полностью согласен (к сожаления не смог вас идентифицировать). И действительно "Главный вопрос современности, не как удушить ваш монолит, а в каком случае вам вообще стоит использовать микросервисы и для чего они нужны ", но данная статья ни в коем случае не была направлена на выбор архитектур, да и рассчитана немного на другую аудиторию, на тех молодых специалистов кому (бородатые дядьки) сказали "делаем MSA", и тут зачастую начинается изобретение велосипеда.
А по поводу выбора архитектуры, особенно MSA, на эту тему надо делать отдельную статью, но размещать ее надо будет в разделе "Философия" т.к. тут сколько люде, столько и мнений. Я сам считаю, что к выбору MSA надо подходить крайне осторожно и продуманно, т.к. недостатков и сложностей у этой архитектуры очень много. Скажу больше, лично я считаю, что часть того, что принято считать достоинствами MSA, является ее недостатками. :-) И зачастую переход на микросервисы продиктован "модой", а не реальной необходимостью.
Но повторюсь это отдельная тема. И нам все равно не никуда не деться от микросервисов (по крайней мере в ближайшем будущем) и значит нужно уметь их проектировать и понимать как они работают.
Если вы считаете, что нужно держать изменяемые данные вместе, то ваш путь - монолит. В MSA так не работает, держать все данные в одном месте нонсенс, например, я не смогу при проведении банковского платежа (одна бизнес операция) смешать все в кучу, уменьшение лимитов, расчет комиссии, хранение истории. И т.к. это разные сервисы, то сразу возникает распределенная транзакция и проблема согласованности данных. А как ее решать, сага или не сага, тут уж каждый решает сам, не нравится сага, придумываем свое решие, и возможно потом появится новый потерн.