Моя телега t.me/softwareengineervlog

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

По-моему, Мартин в первую очередь как раз объясняет различия между хорошей архитектурой со слабым зацеплением и сильной связностью и плохой, когда наоборот, и приводит пример, когда сервисы сильно зацеплены и соответственно при изменении данных, это изменение проходит через все сервисы - как пример как раз плохой архитектуры. Далее он объясняет принципы разбиения на компоненты, чтобы уменьшить зацепление и увеличить связность, и говорит, что компонент это может быть как либа, так и сервис. Эта основная идея и заложена в Agile principles и Clean architecture Мартина, причем вторая книга действительно довольно поверхностно проходится по проблеме (у нее и объем 200-300 страниц), возможно поэтому складывается такое впечатление что Мартин топит против SoA, но это не так. Он топит против именно кривого SoA и объясняет, что сам по себе SoA, то есть микросервисы - не панацея, и там точно также важна правильная, "чистая", архитектура. В Agile principles есть даже отдельный пример иллюстрирующий этот случай.

За вектор поразмыслить - лайк Соеру! Особенно за… несколько часов - прочитал 🤪 📚

Гладко было на бумаге, но забыли про овраги Джуны пишут сервера, старички побитые опытом пишут сервисы…даже в монолите можно написать описанный сервис Написать правильно новую службу, это дорого и требует огромных навыков у руководства (лиды, архитекторы, овнеры)…реальность слишком сурова… ещё и скрам подходы часто трактуются таким образом, что спринт производит юзер стори, если юзер не пощупал в конце спринта, значит ничего не наработали…вот из-за этого много кто разрабатывает апи сервиса и сразу же его интегрирует в одном спринте, редактируя по пути версию апи и клиентский код. Да и для бизнеса требования к сервису, часто это потребности клиентского кода. В видео примеры сервисов это уже устоявшиеся службы, почтовик, БД и т.д. Где АПИ разработан десятки лет назад (SQL это АПИ) Возможно стоит прокачивать навыки создания того самого апи и думать не от потребностей клиента, например в этой книге много материалов на подумать Проектирование веб АПИ (Арно Лоре)

Спасибо за труд, никогда не задумывался над такими, казалось бы, незначительными семантическими деталями, но после просмотра ваших видео начинаю по другому смотреть на многие вещи в своей работе.

А теперь бы про микросервисы, и их место в сервисно-ориентированной архитектуре

Спасибо за видео! Хорошое объяснение. До этого момента я думал что микросервисная архитектура это модная безсмыслица.

Очень хорошую мысль извлёк из ваших слов и мнения. Спасибо вам большое!

Интересно было бы послушать про микросервисы!

Потому что их одобрил дядя Сэм 👉. Не знаю как на беке - на фронте микрофронтенды помагают увеличить объемы работы, занять по больше персонала и отмыть по больше баблишек.

Интересно, благодарю

Вот бы теперь послушать чем отличаются сервисы и микросервисы

Спасибо за разъяснение!

Спасибо!

Сделай выпуск пожалуйста подробнее про микросервисы, почему везде в паутине твердят что Go лучший язык для них?

Спасибо, нашёл 4 книги Роберта Мартина. Прочитаю обязательно.

... пишите монолиты, когда и если придёт время нужды в "сервисах" к тому моменту вы уже должны быть в состоянии отдать на аутсорс, или начинайте писать новый монолит ))

а как субд нам может отказать в обслуживании?

Интересно, но водички много.

Сервисный сервис

На мой взгляд, зацепление тут не при чем. Сервис - это терминология логического (абстрактного, доменного) уровня, а сервер - это техническое (физическое) понятие. Зацепление же - мера взаимосвязи. Сервер может предоставлять разные сервисы или не предоставлять вообще (какие-нибудь крон джобы). И у сервера может быть как низкое так и высокое зацепление и у сервиса. Если утрировать, это как сказать что если у чего-то скорость низкая то оно теплое, если высокая - оно мягкое. Короче, немного бредово, как по мне.

Я всё думаю в бд связь one to mony albums, genres вот думаю в NestJs контролере дёргать 2 сервиса или создать 2 метода 1 сервиса или в сервисе дёргать 2 репозитория или фильтровать с помощью queryParams по году и жанру с одим сервисом, контролером и репозиторием) В angulare с сервисами проще)

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

Так и не понял почему дядя Боб обидел сервисы

Думаю, что для ясного понимания необходимо точно переводить "service" и однозначно называть по-русски что подразумеваешь под словом "сервис": 1.Услуга. 2.Обслуживание. 3.Служба.

Что-то лайков маловато

Возвращение ошибки с сервера не есть отказ от выполнения обслуживания?

Ну не знаю... Вот допустим разработчики стороннего сервиса - решил поменять свое апи, и при этом забил на обратную совместимость. Что с этим делать? Ну, типа для примера та же СУБД, вот решили разработчики - что Дата-Время без часового пояса не имеет смысла, с новым апдейтом - все ваши транзакции без пояса - отфутболиваются и настойчиво просят дату-время. Вы конечно можете перейти на другую СУБД, но у вас много своего кода, плюс плюшек куча у той СУБД и вообще, в итоге - вы скорее намутите во всех местах со врпеменем-датой какой-нибудь костыль(ну или баналный перехватчик делаете, который добавляет этот самый часовой пояс если надо), чтобы таки время-дату использовать, если хотите последнюю версию использовать. А возможно вы и хотите, ведь помимо вот таких вот ломающих изменений - там нужные вам плюшки, которых еще и ни у кого нет, еще и миллионы денег заплочены. Короче. Я к чему. К тому что видимо я что-то не понимаю.

Использовать слова "служба" и "сервис" как имеющие разный смысл в русском языке намного проще, чем в английском.

Дичь лютая! "Сервис, сильно зацепленный на логику вашего приложения, является просто вынесенной службой." А слово service как с английского переводится? Чуть ранее в качестве сервиса была упомянута СУБД. ЧЁ??? Где тут низкое зацепление? Разве приложение не содержит слой моделей, которые в точности повторяют структуру таблиц? Или, может быть, приложение продолжает работать после того, как сервер БД прилег?

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