День шестьсот сорок первый. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 6/7
L - Слабая связанность (Loose coupling)
В разработке ПО связанность означает степень взаимозависимости между двумя элементами ПО. Для систем, основанных на сервисах, связанность определяется тем, как пользователи сервиса взаимодействуют с сервисом. Мы знаем, что это взаимодействие должно осуществляться через контракт на обслуживание. Кроме того, контракт не должен быть тесно связан с деталями реализации или конкретной технологией. Сервис - это распределённый компонент, который может вызываться разными программами. Иногда хозяин сервиса даже не знает, где находятся все его пользователи (часто так бывает в случае сервисов c публичным API). Таким образом, следует избегать изменения контракта. Если сервисный контракт тесно связан с сервисной логикой или технологией, то он более подвержен изменениям, по мере развития логики или технологии.

Сервисам часто необходимо взаимодействовать с другими сервисами или другими типами компонентов, создавая таким образом эфферентную связь. Это взаимодействие устанавливает зависимости времени выполнения, которые напрямую влияют на автономность службы. Чем менее автономен сервис, тем менее предсказуемо его поведение: в лучшем случае он будет настолько быстрым, надежным и доступным, как самый медленный, наименее надёжный и наименее доступный компонент, который ему нужно вызвать.

Стратегии слабой связанности для сервисов
Буква L в IDEALS советует быть внимательными к связям сервисов и, следовательно, микросервисов. Можно использовать и комбинировать несколько стратегий, чтобы способствовать слабой связанности:
1. Точка-точка и публикация-подписка: эти стандартные шаблоны обмена сообщениями и их вариации способствуют ослаблению связанности, поскольку отправители и получатели не знают друг друга; контракт реактивного микросервиса становится именем и структурой сообщения в очереди.
2. API-шлюз и BFF: промежуточный компонент, который устраняет любые несоответствия между контрактом службы и форматом сообщения или протоколом, который клиент хочет видеть, тем самым помогая их разъединить.
3. Разработка через контракт: разрабатывая контракт независимо от любого существующего кода, мы избегаем создания API-интерфейсов, тесно связанных с технологией и реализацией.
4. Гипермедиа: для сервисов REST гипермедиа помогает интерфейсам быть более независимыми от конечных точек.
5. Паттерны Фасад и Адаптер: вариации этих шаблонов GoF в микросервисных архитектурах могут предполагать наличие внутренних компонентов или даже сервисов, которые предотвращают нежелательное связывание в реализации микросервиса.
6. База данных на каждый микросервис: микросервисы не только получают автономию, но и избегают прямого подключения к общим базам данных.

Окончание следует…

Источник: https://www.infoq.com/articles/microservices-design-ideals/