Один из недооценённых скиллов в разработке — это умение провести правильную границу между сервисами. Большинство «распределённых монолитов», которые мы встречаем в продакшене, рождаются именно здесь.
Разобрали тему — держи шпаргалку 👇
🔹 Что такое Service Boundary
Это контракт на три вещи:
— за что сервис отвечает;
— какими данными он владеет;
— как он общается с соседями.
Пример: в компании HR не лезет в финансы, а склад не занимается зарплатами. Так же должны работать твои сервисы.
🔹 4 принципа, которые работают
1. Business Capability First
Режь по бизнес-функциям, а не по техническим слоям. OrderService, PaymentService, UserService — потому что именно так бизнес думает о системе.
2. Single Responsibility
Один сервис — одна ответственность. Если в описании сервиса есть союз «и», это уже тревожный звоночек 🚨
3. Data Ownership
У каждого сервиса своя БД. Без исключений. Shared database = shared pain.
4. Loose Coupling
Только API, никакого прямого доступа к чужим таблицам.
🔹 Классический антипаттерн
// ❌ Бизнес-логика смешана в одном сервисе
class BadOrderService
{
public function processOrderAndPayment(int $id): string
{
$order = $this->orderRepository->findById($id)
?? 'Order not found';
$paymentStatus = 'Payment Successful'; // 🚨 чужая ответственность
return $order . ' | ' . $paymentStatus;
}
}
Выглядит безобидно, пока не нужно масштабировать платежи отдельно, сменить платёжного провайдера или добавить retry-логику только для оплаты. Тут и начнутся реальные проблемы.
🔹 Советы из практики
→ Начни с монолита. Не дроби систему заранее. Сначала пойми домен, потом режь по швам.
→ Следи за chatty communication. Если сервис делает 10 вызовов к соседям на каждый запрос — граница явно проведена не там.
→ Изучи DDD. Bounded Context из Domain-Driven Design — лучший инструмент для поиска правильных границ. Инвестиция окупается быстро.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥1