я понимаю что это подкаст но данную тему мне кажется стоит визуализировать и показывать конкретные примеры когда плохо, и когда хорошо с данными и диаграммой общения между сервисами тогда и проще, чем в голове это представлять, и выводы лучше запоминаются
Так все вроде просто. Если я правильно понял, то задача должна быть максимально конкретной, тогда она будет универсальной по внешним признакам. Прасинг Json файлов конкретная задача? Да. И при этом она нужна везде. Но ей грозит отдельная функция, а не сервис. Поэтому второе требование, задача должна потреблять ресурсы, чтобы ее было рентабельно выносить. Автор же привел в пример задачу хранения данных, почтовый сервис и онлайн карты. Мне приходит в голову распознавание лиц, маршрутизация, оркестрация, логирование с аналитикой. Если разбивать бизнес логику, тот тут надо прогнозировать, это уже не из области паттернов, а про аналитику. Вообще советуют начать с монолита, а потом отделять. А так принцип тот же что и везде. Что функция, что класс, что компонент должны выполнять конкретную задачу, тогда в больше всяких мест их можно будет запихнуть))) Это и есть low coupling, high cohesion.
По-моему, Мартин в первую очередь как раз объясняет различия между хорошей архитектурой со слабым зацеплением и сильной связностью и плохой, когда наоборот, и приводит пример, когда сервисы сильно зацеплены и соответственно при изменении данных, это изменение проходит через все сервисы - как пример как раз плохой архитектуры. Далее он объясняет принципы разбиения на компоненты, чтобы уменьшить зацепление и увеличить связность, и говорит, что компонент это может быть как либа, так и сервис. Эта основная идея и заложена в Agile principles и Clean architecture Мартина, причем вторая книга действительно довольно поверхностно проходится по проблеме (у нее и объем 200-300 страниц), возможно поэтому складывается такое впечатление что Мартин топит против SoA, но это не так. Он топит против именно кривого SoA и объясняет, что сам по себе SoA, то есть микросервисы - не панацея, и там точно также важна правильная, "чистая", архитектура. В Agile principles есть даже отдельный пример иллюстрирующий этот случай.
Гладко было на бумаге, но забыли про овраги Джуны пишут сервера, старички побитые опытом пишут сервисы…даже в монолите можно написать описанный сервис Написать правильно новую службу, это дорого и требует огромных навыков у руководства (лиды, архитекторы, овнеры)…реальность слишком сурова… ещё и скрам подходы часто трактуются таким образом, что спринт производит юзер стори, если юзер не пощупал в конце спринта, значит ничего не наработали…вот из-за этого много кто разрабатывает апи сервиса и сразу же его интегрирует в одном спринте, редактируя по пути версию апи и клиентский код. Да и для бизнеса требования к сервису, часто это потребности клиентского кода. В видео примеры сервисов это уже устоявшиеся службы, почтовик, БД и т.д. Где АПИ разработан десятки лет назад (SQL это АПИ) Возможно стоит прокачивать навыки создания того самого апи и думать не от потребностей клиента, например в этой книге много материалов на подумать Проектирование веб АПИ (Арно Лоре)
Спасибо за труд, никогда не задумывался над такими, казалось бы, незначительными семантическими деталями, но после просмотра ваших видео начинаю по другому смотреть на многие вещи в своей работе.
Потому что их одобрил дядя Сэм 👉. Не знаю как на беке - на фронте микрофронтенды помагают увеличить объемы работы, занять по больше персонала и отмыть по больше баблишек.
Ну типа сравнительно простой в изучении, довольно шустрый, нет многотонных фреймворков, собирается всего в один бинарник (можно упростить процесс деплоя). В остальном такой же яп как и все остальные...
1. Быстрая компиляция - в отличие от других компилируемых языков 2. Достаточно простой синтаксис - в отличие от C++ или Rust 3. Скорость выполнения с CG - в отличие интерпретируемых языков и даже в какой-то мере по сравнению с языками, которые выполняются с помощью VM 4. Легкая и понятная многопоточность (для тяжелых сервисов это особенно важно) - в отличие от любого другого языка, который ее поддерживает 5. Статическая типизация - в отличие от JS или Python 6. Стандартная библиотека в большинстве случаев обеспечит все, что необходимо, чтобы запустить микросервис без чего бы то ни было еще. Просто запустил бинарные и сервис работает.
... пишите монолиты, когда и если придёт время нужды в "сервисах" к тому моменту вы уже должны быть в состоянии отдать на аутсорс, или начинайте писать новый монолит ))
я так понял, сервис это отдельное маленькое приложение, из этих мини приложений как конструктор собирается большое приложение... если нам какой-то сервис не подходит, легко заменяем его, при этом само приложение не меняется.. а что тогда приложение? это только название, обедняющее различные сервисы?
Я всё думаю в бд связь one to mony albums, genres вот думаю в NestJs контролере дёргать 2 сервиса или создать 2 метода 1 сервиса или в сервисе дёргать 2 репозитория или фильтровать с помощью queryParams по году и жанру с одим сервисом, контролером и репозиторием) В angulare с сервисами проще)
Вы не про те сервисы думаете) В данном видео речь идёт о сервисе который поднимается как отдельное приложение в рамках другого процесса и общается с вашим приложением через HTTP запросы, а не сервис в виде класса в вашей приложеньке. Вы думаете о сервисах в контексте DDD, а тут этот термин используется в рамках сервисной или микросервисной архитектур, что совершенно разные вещи.
Да. Ошибка от СУБД означает, что "я не понял, что ты имеешь в виду и не могу выполнить запрос. Если напишешь запрос, который я пойму, то выполню". Потому что это СУБД. И она не вернёт ошибку если ресурс просто не найден.
На мой взгляд, зацепление тут не при чем. Сервис - это терминология логического (абстрактного, доменного) уровня, а сервер - это техническое (физическое) понятие. Зацепление же - мера взаимосвязи. Сервер может предоставлять разные сервисы или не предоставлять вообще (какие-нибудь крон джобы). И у сервера может быть как низкое так и высокое зацепление и у сервиса. Если утрировать, это как сказать что если у чего-то скорость низкая то оно теплое, если высокая - оно мягкое. Короче, немного бредово, как по мне.
Ну не знаю... Вот допустим разработчики стороннего сервиса - решил поменять свое апи, и при этом забил на обратную совместимость. Что с этим делать? Ну, типа для примера та же СУБД, вот решили разработчики - что Дата-Время без часового пояса не имеет смысла, с новым апдейтом - все ваши транзакции без пояса - отфутболиваются и настойчиво просят дату-время. Вы конечно можете перейти на другую СУБД, но у вас много своего кода, плюс плюшек куча у той СУБД и вообще, в итоге - вы скорее намутите во всех местах со врпеменем-датой какой-нибудь костыль(ну или баналный перехватчик делаете, который добавляет этот самый часовой пояс если надо), чтобы таки время-дату использовать, если хотите последнюю версию использовать. А возможно вы и хотите, ведь помимо вот таких вот ломающих изменений - там нужные вам плюшки, которых еще и ни у кого нет, еще и миллионы денег заплочены. Короче. Я к чему. К тому что видимо я что-то не понимаю.
Это какая же такая СУБД, чтоб разработчики так извращались? Само ядро любой СУБД это ее типы данных, разработанные раз и навсегда. Изменив что-то в типах можно просто выкинуть продукт на помойку. Вы о чём? О самописной может?
@@itcloudguy Пример был гипотетический, на основе реального провайдера pgSql для efCore в дотнете, когда в разработчики с той стороны решили, что все, мы будем кидать эксепшн если не передать таймзону для полей с временем(те что просто DateTime). Да, там дали возможность и по старому работать, но пометили это как легаси. Ну так вот, из-за этого, конкретно у нас - пришлось на время всю разработку остановить. А почему? Потому что - вот, они порешали, что не кошерно и вообще - в дотнете некрутое время, а мы - хотим круто, потому - страдайте. Весело - офигеть.
Думаю, что для ясного понимания необходимо точно переводить "service" и однозначно называть по-русски что подразумеваешь под словом "сервис": 1.Услуга. 2.Обслуживание. 3.Служба.
Вы затронули очень острую тему, сейчас такой хейт поднимется. А по-существу, конечно же, правильно. Причём, не только для темы данного ролика - это повсеместно. Иногда можно увидеть целые лекции, где люди пытаются объяснить что-то, хотя достаточно было бы дать точный, не синонимичный перевод. Достаточно взглянуть на инструкцию к любому лекарству в аптеке, чтобы осознать масштаб языковой катастрофы.
@@itcloudguy Вот и я о том. Автор ролика использует эти слова как имеющие разный смысл. И очень интересно, какой англоязычный смысл он имеет в виду, говоря "служба".
Дичь лютая! "Сервис, сильно зацепленный на логику вашего приложения, является просто вынесенной службой." А слово service как с английского переводится? Чуть ранее в качестве сервиса была упомянута СУБД. ЧЁ??? Где тут низкое зацепление? Разве приложение не содержит слой моделей, которые в точности повторяют структуру таблиц? Или, может быть, приложение продолжает работать после того, как сервер БД прилег?
Это вы путаете, потому что связанность это и есть зацепление (coupling), вы перепутали ее со связностью (cohesion), что суть характеристика модуля, когда в нем содержатся близкие по смыслу концепции (это хорошо). Зацепление - это плохо, это количество внешних зависимостей модуля, чем их больше, тем меньше связность модуля и тем хуже.
![Как устроен QR-код? [Veritasium]](/img/1.gif)
Моя телега t.me/softwareengineervlog
я понимаю что это подкаст
но данную тему мне кажется стоит визуализировать и показывать конкретные примеры когда плохо, и когда хорошо
с данными и диаграммой общения между сервисами
тогда и проще, чем в голове это представлять, и выводы лучше запоминаются
Так все вроде просто. Если я правильно понял, то задача должна быть максимально конкретной, тогда она будет универсальной по внешним признакам. Прасинг Json файлов конкретная задача? Да. И при этом она нужна везде. Но ей грозит отдельная функция, а не сервис. Поэтому второе требование, задача должна потреблять ресурсы, чтобы ее было рентабельно выносить. Автор же привел в пример задачу хранения данных, почтовый сервис и онлайн карты. Мне приходит в голову распознавание лиц, маршрутизация, оркестрация, логирование с аналитикой. Если разбивать бизнес логику, тот тут надо прогнозировать, это уже не из области паттернов, а про аналитику. Вообще советуют начать с монолита, а потом отделять. А так принцип тот же что и везде. Что функция, что класс, что компонент должны выполнять конкретную задачу, тогда в больше всяких мест их можно будет запихнуть))) Это и есть low coupling, high cohesion.
По-моему, Мартин в первую очередь как раз объясняет различия между хорошей архитектурой со слабым зацеплением и сильной связностью и плохой, когда наоборот, и приводит пример, когда сервисы сильно зацеплены и соответственно при изменении данных, это изменение проходит через все сервисы - как пример как раз плохой архитектуры. Далее он объясняет принципы разбиения на компоненты, чтобы уменьшить зацепление и увеличить связность, и говорит, что компонент это может быть как либа, так и сервис.
Эта основная идея и заложена в Agile principles и Clean architecture Мартина, причем вторая книга действительно довольно поверхностно проходится по проблеме (у нее и объем 200-300 страниц), возможно поэтому складывается такое впечатление что Мартин топит против SoA, но это не так. Он топит против именно кривого SoA и объясняет, что сам по себе SoA, то есть микросервисы - не панацея, и там точно также важна правильная, "чистая", архитектура. В Agile principles есть даже отдельный пример иллюстрирующий этот случай.
Гладко было на бумаге, но забыли про овраги
Джуны пишут сервера, старички побитые опытом пишут сервисы…даже в монолите можно написать описанный сервис
Написать правильно новую службу, это дорого и требует огромных навыков у руководства (лиды, архитекторы, овнеры)…реальность слишком сурова… ещё и скрам подходы часто трактуются таким образом, что спринт производит юзер стори, если юзер не пощупал в конце спринта, значит ничего не наработали…вот из-за этого много кто разрабатывает апи сервиса и сразу же его интегрирует в одном спринте, редактируя по пути версию апи и клиентский код. Да и для бизнеса требования к сервису, часто это потребности клиентского кода.
В видео примеры сервисов это уже устоявшиеся службы, почтовик, БД и т.д.
Где АПИ разработан десятки лет назад (SQL это АПИ)
Возможно стоит прокачивать навыки создания того самого апи и думать не от потребностей клиента, например в этой книге много материалов на подумать
Проектирование веб АПИ (Арно Лоре)
За вектор поразмыслить - лайк Соеру! Особенно за… несколько часов - прочитал 🤪 📚
Техника чтения накось
Очень хорошую мысль извлёк из ваших слов и мнения. Спасибо вам большое!
Спасибо за труд, никогда не задумывался над такими, казалось бы, незначительными семантическими деталями, но после просмотра ваших видео начинаю по другому смотреть на многие вещи в своей работе.
Вот бы теперь послушать чем отличаются сервисы и микросервисы
А теперь бы про микросервисы, и их место в сервисно-ориентированной архитектуре
Интересно было бы послушать про микросервисы!
Спасибо за видео! Хорошое объяснение. До этого момента я думал что микросервисная архитектура это модная безсмыслица.
Интересно, благодарю
Спасибо за разъяснение!
Потому что их одобрил дядя Сэм 👉. Не знаю как на беке - на фронте микрофронтенды помагают увеличить объемы работы, занять по больше персонала и отмыть по больше баблишек.
так же и на бэке
На бэке еще хуже, там появляется необходимость распределенных транзакций и проблемы многопоточности
@@drovoseg Можно добавить - отсутствие архитектора
а как субд нам может отказать в обслуживании?
Сделай выпуск пожалуйста подробнее про микросервисы, почему везде в паутине твердят что Go лучший язык для них?
Ну типа сравнительно простой в изучении, довольно шустрый, нет многотонных фреймворков, собирается всего в один бинарник (можно упростить процесс деплоя). В остальном такой же яп как и все остальные...
1. Быстрая компиляция - в отличие от других компилируемых языков
2. Достаточно простой синтаксис - в отличие от C++ или Rust
3. Скорость выполнения с CG - в отличие интерпретируемых языков и даже в какой-то мере по сравнению с языками, которые выполняются с помощью VM
4. Легкая и понятная многопоточность (для тяжелых сервисов это особенно важно) - в отличие от любого другого языка, который ее поддерживает
5. Статическая типизация - в отличие от JS или Python
6. Стандартная библиотека в большинстве случаев обеспечит все, что необходимо, чтобы запустить микросервис без чего бы то ни было еще. Просто запустил бинарные и сервис работает.
... пишите монолиты, когда и если придёт время нужды в "сервисах" к тому моменту вы уже должны быть в состоянии отдать на аутсорс, или начинайте писать новый монолит ))
Спасибо!
Спасибо, нашёл 4 книги Роберта Мартина. Прочитаю обязательно.
я так понял, сервис это отдельное маленькое приложение, из этих мини приложений как конструктор собирается большое приложение... если нам какой-то сервис не подходит, легко заменяем его, при этом само приложение не меняется.. а что тогда приложение? это только название, обедняющее различные сервисы?
да
Я всё думаю в бд связь one to mony albums, genres вот думаю в NestJs контролере дёргать 2 сервиса или создать 2 метода 1 сервиса или в сервисе дёргать 2 репозитория или фильтровать с помощью queryParams по году и жанру с одим сервисом, контролером и репозиторием) В angulare с сервисами проще)
Вы не про те сервисы думаете) В данном видео речь идёт о сервисе который поднимается как отдельное приложение в рамках другого процесса и общается с вашим приложением через HTTP запросы, а не сервис в виде класса в вашей приложеньке. Вы думаете о сервисах в контексте DDD, а тут этот термин используется в рамках сервисной или микросервисной архитектур, что совершенно разные вещи.
@@bubblesort6368понял спосибо у меня монолит)
Возвращение ошибки с сервера не есть отказ от выполнения обслуживания?
Да. Ошибка от СУБД означает, что "я не понял, что ты имеешь в виду и не могу выполнить запрос. Если напишешь запрос, который я пойму, то выполню". Потому что это СУБД. И она не вернёт ошибку если ресурс просто не найден.
ХОРОШИЙ ОБЗОР ))
Интересно, но водички много.
Так и не понял почему дядя Боб обидел сервисы
На мой взгляд, зацепление тут не при чем. Сервис - это терминология логического (абстрактного, доменного) уровня, а сервер - это техническое (физическое) понятие. Зацепление же - мера взаимосвязи. Сервер может предоставлять разные сервисы или не предоставлять вообще (какие-нибудь крон джобы). И у сервера может быть как низкое так и высокое зацепление и у сервиса. Если утрировать, это как сказать что если у чего-то скорость низкая то оно теплое, если высокая - оно мягкое. Короче, немного бредово, как по мне.
Речь же про "софтварный" сервер, в контексте "клиент-серверного" взаимодействия. А "сервис" в контексте SOA и далее вся разница в видео разжевана.
Сервисный сервис
Ну не знаю...
Вот допустим разработчики стороннего сервиса - решил поменять свое апи, и при этом забил на обратную совместимость. Что с этим делать?
Ну, типа для примера та же СУБД, вот решили разработчики - что Дата-Время без часового пояса не имеет смысла, с новым апдейтом - все ваши транзакции без пояса - отфутболиваются и настойчиво просят дату-время. Вы конечно можете перейти на другую СУБД, но у вас много своего кода, плюс плюшек куча у той СУБД и вообще, в итоге - вы скорее намутите во всех местах со врпеменем-датой какой-нибудь костыль(ну или баналный перехватчик делаете, который добавляет этот самый часовой пояс если надо), чтобы таки время-дату использовать, если хотите последнюю версию использовать. А возможно вы и хотите, ведь помимо вот таких вот ломающих изменений - там нужные вам плюшки, которых еще и ни у кого нет, еще и миллионы денег заплочены.
Короче. Я к чему. К тому что видимо я что-то не понимаю.
Это какая же такая СУБД, чтоб разработчики так извращались? Само ядро любой СУБД это ее типы данных, разработанные раз и навсегда. Изменив что-то в типах можно просто выкинуть продукт на помойку. Вы о чём? О самописной может?
@@itcloudguy Пример был гипотетический, на основе реального провайдера pgSql для efCore в дотнете, когда в разработчики с той стороны решили, что все, мы будем кидать эксепшн если не передать таймзону для полей с временем(те что просто DateTime). Да, там дали возможность и по старому работать, но пометили это как легаси.
Ну так вот, из-за этого, конкретно у нас - пришлось на время всю разработку остановить. А почему? Потому что - вот, они порешали, что не кошерно и вообще - в дотнете некрутое время, а мы - хотим круто, потому - страдайте. Весело - офигеть.
Думаю, что для ясного понимания необходимо точно переводить "service" и однозначно называть по-русски что подразумеваешь под словом "сервис":
1.Услуга.
2.Обслуживание.
3.Служба.
Вы затронули очень острую тему, сейчас такой хейт поднимется. А по-существу, конечно же, правильно. Причём, не только для темы данного ролика - это повсеместно. Иногда можно увидеть целые лекции, где люди пытаются объяснить что-то, хотя достаточно было бы дать точный, не синонимичный перевод. Достаточно взглянуть на инструкцию к любому лекарству в аптеке, чтобы осознать масштаб языковой катастрофы.
Что-то лайков маловато
Использовать слова "служба" и "сервис" как имеющие разный смысл в русском языке намного проще, чем в английском.
Они не о разном смысле. Слово "сервис" - иностранное. И на русском означает "служба". Никак иначе.
@@itcloudguy Вот и я о том. Автор ролика использует эти слова как имеющие разный смысл. И очень интересно, какой англоязычный смысл он имеет в виду, говоря "служба".
Дичь лютая!
"Сервис, сильно зацепленный на логику вашего приложения, является просто вынесенной службой." А слово service как с английского переводится?
Чуть ранее в качестве сервиса была упомянута СУБД. ЧЁ??? Где тут низкое зацепление? Разве приложение не содержит слой моделей, которые в точности повторяют структуру таблиц? Или, может быть, приложение продолжает работать после того, как сервер БД прилег?
Побуду немного душным и скажу, что вы путаете связанность с зацеплением
Это вы путаете, потому что связанность это и есть зацепление (coupling), вы перепутали ее со связностью (cohesion), что суть характеристика модуля, когда в нем содержатся близкие по смыслу концепции (это хорошо). Зацепление - это плохо, это количество внешних зависимостей модуля, чем их больше, тем меньше связность модуля и тем хуже.
@@AlexP-jc7rz Оу, благодарю, буду внимательнее