а что ещё делать с микросервисами, кроме того, как нагрузку с монолита снимать?

а что ещё делать с микросервисами, кроме того, как нагрузку с монолита снимать?

писать про них статьи и упоминать в резюме

писать про них статьи и упоминать в резюме

Ну не

пока это самое эффективное, что можно сделать

Помогает же распараллелить разработку

писать про них статьи и упоминать в резюме

А это аргумент кстати. Как и блокчеин

а что ещё делать с микросервисами, кроме того, как нагрузку с монолита снимать?

там больше про скейлинг людей

А это аргумент кстати. Как и блокчеин

именно. сразу +50 к крутости

что бы каждая команда в рамках большого проекта могла практиковать и CI и CD и все эти лин штуки

если у тебя этого нет и релизы раз в месяц - тебе точно микросервисы не нужны)

ну а все остальное - приятный побочный эффект)

что бы каждая команда в рамках большого проекта могла практиковать и CI и CD и все эти лин штуки

за что мне нравится этот канал, почитал, погуглил, узнал новое )))

Когда Я работал в одном крупнейшем Форекс брокере восточной европы) то я не представляю что там был бы за пиздец если бы монолитом все хуярили. Были части бизнеса которые использовались в очень многих местах и их выносили отдельными приложухами

Когда Я работал в одном крупнейшем Форекс брокере восточной европы) то я не представляю что там был бы за пиздец если бы монолитом все хуярили. Были части бизнеса которые использовались в очень многих местах и их выносили отдельными приложухами

как ты относишься к идее "microservice != deployment target"?

При условии соблюдения семвер можно было спокойно пилить свой проект , не мучаясь с конфликтами и не вникая в логику другого. Например я пилил онлайн школу и взаимодействовал с сервисами финансов, и личного кабинета пользователя(На бирже) просто дергая апи.

как ты относишься к идее "microservice != deployment target"?

Нее знаком со вторым термином

При условии соблюдения семвер можно было спокойно пилить свой проект , не мучаясь с конфликтами и не вникая в логику другого. Например я пилил онлайн школу и взаимодействовал с сервисами финансов, и личного кабинета пользователя(На бирже) просто дергая апи.

Это еще не микросервисы так-то

При условии соблюдения семвер можно было спокойно пилить свой проект , не мучаясь с конфликтами и не вникая в логику другого. Например я пилил онлайн школу и взаимодействовал с сервисами финансов, и личного кабинета пользователя(На бирже) просто дергая апи.

Представь, что у тебя было просто пара интерфейсов, которые ты юзал. Сервис там или нет ты бы не знал, что изменилось бы?)

Это еще не микросервисы так-то

Почему? Чего не хватает?

Не буду истиной в последней инстанции, но имхо сути: минимальной связности. То что вы описали вполне себе типичная SOA.

При условии соблюдения семвер можно было спокойно пилить свой проект , не мучаясь с конфликтами и не вникая в логику другого. Например я пилил онлайн школу и взаимодействовал с сервисами финансов, и личного кабинета пользователя(На бирже) просто дергая апи.

"соблюдение семвер"?))))

Представь, что у тебя было просто пара интерфейсов, которые ты юзал. Сервис там или нет ты бы не знал, что изменилось бы?)

В идеальном мире ничего. Но во какие плюсы были: - я не мог ниче поломать в сервисе финансов если бы пришла идея такая - их релиз цикл никак не зависел от моего и наоборот - проще переписать в случае чего( в им числе на другой язык) Но как выше уже выдыигалосо, мне кажется это несет каплинг и кохижен в процесс разработки)) то есть внутри команды сервиса плотное взаимодействие а во т между разными командами лишь открытые порты, к которым каждый хуярит свой адаптер

В идеальном мире ничего. Но во какие плюсы были: - я не мог ниче поломать в сервисе финансов если бы пришла идея такая - их релиз цикл никак не зависел от моего и наоборот - проще переписать в случае чего( в им числе на другой язык) Но как выше уже выдыигалосо, мне кажется это несет каплинг и кохижен в процесс разработки)) то есть внутри команды сервиса плотное взаимодействие а во т между разными командами лишь открытые порты, к которым каждый хуярит свой адаптер

давай представим такой вот ужасный мир, у нас SVN (или любая другая VCS которая умеет разграничивать права на директории).

и монолит, где каждому дано право только свой модуль менять

"соблюдение семвер"?))))

Ну если кто то в минорной версии поломает bc то вся идея идет нах))

При условии соблюдения семвер можно было спокойно пилить свой проект , не мучаясь с конфликтами и не вникая в логику другого. Например я пилил онлайн школу и взаимодействовал с сервисами финансов, и личного кабинета пользователя(На бирже) просто дергая апи.

ну вот в книге говорится, что если ты Дергаешь апи другого, чтобы получить какие-то данные. это плохо. ибо в таком случае это синхронный запрос. и ты просто проиграешь из-за него. т.к. затратишь время на запрос по сети (сериализацию, десерилизацию, передачу и пр).

В идеальном мире ничего. Но во какие плюсы были: - я не мог ниче поломать в сервисе финансов если бы пришла идея такая - их релиз цикл никак не зависел от моего и наоборот - проще переписать в случае чего( в им числе на другой язык) Но как выше уже выдыигалосо, мне кажется это несет каплинг и кохижен в процесс разработки)) то есть внутри команды сервиса плотное взаимодействие а во т между разными командами лишь открытые порты, к которым каждый хуярит свой адаптер

По сравнению с чем эти плюсы?

Ну если кто то в минорной версии поломает bc то вся идея идет нах))

ну вот, начинается хореография

ну вот в книге говорится, что если ты Дергаешь апи другого, чтобы получить какие-то данные. это плохо. ибо в таком случае это синхронный запрос. и ты просто проиграешь из-за него. т.к. затратишь время на запрос по сети (сериализацию, десерилизацию, передачу и пр).

мысль верная, но причина совершенно глупая

причина не в том что там "синхронный запрос"

я лишь описал почему это плохо

и да причина не потомучто синхронный

это плохо потому что это высокий каплинг)

да

давай представим такой вот ужасный мир, у нас SVN (или любая другая VCS которая умеет разграничивать права на директории).

А как быть с разными версиями в таком случае? Кому то нужна 2.5.6 а каким то динозаврам 0.0.г

в книге про это именно и говорится

ну то есть твой микросервис зависит от данных, которые хранит другой микросервис

что синхронный запрос тянет коуплинг за собой

да. все верно

не буду расскрывать публике, какой совет даётся в книге

ибо его тут знают

ответ всмысле :)

наверное он под синхронным запросом подразумевает факт того что мы должны дождаться ответа

в книге про это именно и говорится

Я на сколько понял по введению там он вообще советует все bounded context как отдельные сервисы? И общаться по http

это плохо потому что это высокий каплинг)

высокий каплинг, потому что запросы будут в "очереди"?

Я на сколько понял по введению там он вообще советует все bounded context как отдельные сервисы? И общаться по http

ну как бы... оно как бы так и надо....

высокий каплинг, потому что запросы будут в "очереди"?

ммм нет

Я на сколько понял по введению там он вообще советует все bounded context как отдельные сервисы? И общаться по http

не делай поспешных выводов. просто прочти.

По сравнению с чем эти плюсы?

По сравнению с одним здоровым приложением которое развертывается целиком и в которое все пишут. Ну и инфраструктура общая для всех частей

высокий каплинг, потому что запросы будут в "очереди"?

нет

высокий каплинг, потому что запросы будут в "очереди"?

ну то есть.... каплинг - это когда у тебя одна штука от другой зависит

не делай поспешных выводов. просто прочти.

Эт я давно читал еще, как с компа зайду скину цитату

"легкий" каплинг, это когда ты отправляешь сообщение и не дожидаешься ответа (то что "асинхронным" видимо в книжке этой зовется)

"тяжелый" каплинг - это когда ты из другого модуля достаешь хрень и начинаешь в ней копашиться

есть еще средние каплинги типа "эти два компонента должны быть вызваны примерно в одно и то же время"

высокий каплинг, потому что запросы будут в "очереди"?

можешь почитать Егора Бугаенко на тему геттеров, я думаю тебе хорошо так зайдет)

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

ну или Алана Холуба если посолиднее персонажи тебе больше нравятся

http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

https://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html

где бы времени набрать, всё прочитать? у меня уже в списке книг 5 :(

и да в той книге, про геттеры и сеттеры тоже сказано. что мол это простой подход. когда у ты работаешь как CRUD

это я продолжаю рекламить (сорри)

где бы времени набрать, всё прочитать? у меня уже в списке книг 5 :(

можешь просто упражнения делать)) есть например "объектная гимнастика" - хорошо так мозги поломать заставляет

и да в той книге, про геттеры и сеттеры тоже сказано. что мол это простой подход. когда у ты работаешь как CRUD

мне чем он не нравится - он все слишком упрощает

настолько что местами хорошая идея превращается в херню

ERROR: S client not available

но в целом из твоего описания - книжка в целом не совсем дно

где бы времени набрать, всё прочитать? у меня уже в списке книг 5 :(

ну вот ссылки выше - это минут 20 чтения

мне чем он не нравится - он все слишком упрощает

да. из-за того его книга и названа for everyone. для нубов. она небольшая я за 3 дня прочел. ничего нового для себя не открыл. но его подача понравилась и куча отсылок на другие (более серьезные работы).

нубам бы как модули делать

Кстати, раз такая пьянка, @fes0r, ты смотрел в сторону Workflow мэнеджеров готовых и в частности на BPMN

Кстати, раз такая пьянка, @fes0r, ты смотрел в сторону Workflow мэнеджеров готовых и в частности на BPMN

ммм тебе типа диаграмки рисовать?

я BPMN помню по вкладке на draw.io просто)

или ты хочешь BPMN "компилить" в автомат?

Ммм нет, мне типо диаграмкой описать сагу и спец. софт это дело рулит и сам бегает по сервисам, ждет, переводит статус, откатывает и т.д.

На хабрике тут пару дней назад накидывали

не видал

Вот пытаюсь переварить есть ли от такого подхода какой-то профит

чёт не очень, как по мне)

Вот пытаюсь переварить есть ли от такого подхода какой-то профит

если бы я небыл таким тупым - я бы больше в сторону ML смотрел и прочих OCaml

Статейка: https://habrahabr.ru/post/346630/

Ну и пример такого инструмента: https://camunda.org/

Основной наброс, что бизнес-процессы (именно процессы, а не сущности) надо держать в одном месте.

Ну и важное уточнение от автора которого нет в статье: ... now regarding your comment about ESBs. We actually use the term to separate central components containing certain business logic (like e.g. a bit more complex routing rules wiring together a "business process") from a "dumb pipe", which would e.g. be implemented with some messaging queue, which really just publishes e.g. an event via a topic or routes a command via a queue. So in fact we are very much thinking in terms of asynchronous messaging here, but these commands and events could also be exchanged asynchronously via e.g. REST feeds.

можешь почитать Егора Бугаенко на тему геттеров, я думаю тебе хорошо так зайдет)

холиварная тема... без бутылки никак ))

холиварная тема... без бутылки никак ))

на самом деле не холиварная. Вопрос только в том для чего тебе геттер

сеттеры вообще не нужны, а геттеры все еще полезны когда тебе надо отобразить данные.

но если ты достаешь данные что-бы снаружи объекта логику на этих данных строить - это повод задуматься

возможно, только возможно, что ничего плохого нет и мы имеем дело просто с криво названным методом

но есть вероятность что логика которая тебе нужна должна находиться в самом объекте

и если ты начнешь на эту тему долго думать - это станет логичным)

как это сеттеры не нужны? в конструктор передавать 20 параметров, чтобы инициализировать свойства?

а делать вызовы 20 сеттеров?) кажется, ты не ту проблему решаешь)

и если ты начнешь на эту тему долго думать - это станет логичным)

....толстые модели....

вернёмся к конструктору )

конструктур с 20ю аргументами - явная хрень)

как это сеттеры не нужны? в конструктор передавать 20 параметров, чтобы инициализировать свойства?

проблема в том что у тебя 20 параметров у конструктора - возможно проблема именно в этом?

как это сеттеры не нужны? в конструктор передавать 20 параметров, чтобы инициализировать свойства?

Есди объекту надо 20 параметров то это повод подумать над SRP