Ответ
High Cohesion (Высокая связность) и Low Coupling (Низкое зацепление) — это два фундаментальных принципа проектирования программного обеспечения, которые особенно важны при разработке микросервисов. Они помогают правильно определить границы сервисов.
High Cohesion (Высокая связность)
High Cohesion означает, что все компоненты внутри одного микросервиса (код, данные, логика) тесно связаны друг с другом и служат одной четко определенной бизнес-цели. Сервис должен быть сфокусирован на одной задаче и делать ее хорошо.
- Признак хорошей связности: Если для реализации нового бизнес-требования вам нужно изменить код только в одном сервисе, скорее всего, у него высокая связность.
- Признак плохой связности: Если сервис выполняет множество несвязанных функций (например, управляет и профилями пользователей, и биллингом, и доставкой товаров), у него низкая связность (cohesion).
Low Coupling (Низкое зацепление)
Low Coupling означает, что микросервисы должны быть максимально независимы друг от друга. Изменение в одном сервисе не должно требовать каскадных изменений в других сервисах. Связи между сервисами должны быть минимальными и четко определенными (например, через стабильный API).
- Признак низкого зацепления: Вы можете развернуть новую версию одного сервиса, не затрагивая и не развертывая другие сервисы (при условии сохранения обратной совместимости API).
- Признак высокого зацепления: Сервисы напрямую обращаются к базам данных друг друга или сильно зависят от внутренних деталей реализации других сервисов.
Пример:
Представим e-commerce приложение.
-
Плохой дизайн (Low Cohesion, High Coupling): Один большой сервис
MonolithService, который управляет пользователями, заказами, платежами и уведомлениями. -
Хороший дизайн (High Cohesion, Low Coupling): Система разбита на несколько сфокусированных микросервисов:
AuthService: отвечает только за аутентификацию и авторизацию.OrderService: управляет жизненным циклом заказов.PaymentService: обрабатывает платежи.NotificationService: отправляет email и push-уведомления.
Эти сервисы взаимодействуют друг с другом через четко определенные API (например, OrderService асинхронно сообщает NotificationService о необходимости отправить уведомление), но остаются независимыми в своей реализации и развертывании.
Ответ 18+ 🔞
Давай разберёмся, что за зверь такой — High Cohesion и Low Coupling. Это, блядь, как два столпа, на которых держится вся нормальная архитектура, особенно когда речь про микросервисы. Если их проигнорировать — получится пиздец, а не система.
High Cohesion (Высокая связность)
Это когда всё, что внутри одного сервиса, работает на одну, ёбта, цель. Как будто бригада грузчиков: все таскают коробки, никто не отвлекается на приготовление борща. Сервис должен делать что-то одно, но делать это овердохуища хорошо.
- Понял, что всё окей: Если тебе нужно добавить новую фичу в бизнес-процесс, и ты лезешь менять код только в одном сервисе — связность высокая. Красота!
- Понял, что пиздец: Если твой сервис занимается одновременно расчётом кредитов, отправкой спама и управлением доставкой пиццы — это не сервис, это помойка. Связность ниже плинтуса.
Low Coupling (Низкое зацепление)
А это про то, чтобы сервисы не были, как сиамские близнецы, сросшиеся жопами. Они должны быть независимыми, сука! Изменения в одном не должны вызывать цепную реакцию ебала у всех остальных. Общаются они только через чёткие, стабильные договорённости — API.
- Правильно: Ты катишь новую версию
PaymentService, аOrderServiceдаже не чихнул. Они общаются по старому контракту, и всем похуй, что внутри. - Полный пиздец: Сервисы лезут друг другу прямо в базы данных, как в чужой холодильник, или знают про внутренние костыли соседа. Один чих — и вся система в соплях. Это высокое зацепление, и это хуйня.
Смотри, как это выглядит на практике
Допустим, у нас интернет-магазин.
-
Архитектура от мудака (Low Cohesion, High Coupling): Один жирный сервис
GodService. Он и пользователей создаёт, и заказы обрабатывает, и деньги с карты стрижёт, и смс-ки шлёт. Куча всего, а в итоге — монстр, которого никто не понимает. Хуй сломаешь, пока допишешь в него новую строчку. -
Архитектура по уму (High Cohesion, Low Coupling): Делим всё на нормальные, чёткие куски:
AuthService— пусть только логины-пароли валидирует, ебать его в сраку.OrderService— его дело — заказы. Создал, сохранил, статус поменял.PaymentService— стучится к платёжке и радуется, когда деньги пришли.NotificationService— тупая мартышлюшка, которая шлёт письма и пуши.
Эти ребята общаются между собой через асинхронные сообщения или чёткие HTTP-вызовы. OrderService может сказать: «Эй, NotificationService, заказ №666 создан, нахуярь пользователю письмо». И всё. Как NotificationService это сделает — его личное дело, хоть через дымовые сигналы. Главное — контракт. И разворачивать их можно по отдельности. Вот это и есть красота.