В каком направлении строятся зависимости между слоями в микросервисной архитектуре?

Направление зависимостей в микросервисной архитектуре

В микросервисной архитектуре зависимости между слоями внутри одного сервиса традиционно строятся от внешних слоёв к внутренним (снаружи внутрь), что соответствует принципам чистой архитектуры и гексагональной архитектуры (ports & adapters). Это направление часто называют «зависимостью к центру» или «правилом зависимостей внутрь».

Ключевые принципы организации слоёв

1. Направление зависимостей: снаружи → внутрь

Внутренние слои не зависят от внешних. Внешние слои зависят от абстракций (интерфейсов), определённых во внутренних слоях.

// Внутренний слой (доменная логика) - НЕ зависит от внешних слоёв
namespace App\Domain\Order;

interface OrderRepositoryInterface // Порт (интерфейс)
{
    public function findById(int $id): ?Order;
}

class Order // Сущность (Entity)
{
    private int $id;
    private string $status;
    
    public function markAsPaid(): void
    {
        $this->status = 'paid';
    }
}

// Внешний слой (инфраструктура) - зависит от интерфейсов доменного слоя
namespace App\Infrastructure\Persistence;

use App\Domain\Order\OrderRepositoryInterface;
use App\Domain\Order\Order;

class DatabaseOrderRepository implements OrderRepositoryInterface // Адаптер
{
    public function findById(int $id): ?Order
    {
        // Реализация работы с БД
    }
}

2. Типичные слои в микросервисе (от внешних к внутренним):

• Transport/API Layer (Контроллеры, маршруты, CLI-команды)

  • Принимает HTTP-запросы, команды CLI, сообщения из очереди
  • Валидирует входные данные
  • Зависит от слоя приложения

• Application Layer (Сервисы приложения, Use Cases)

  • Оркестрирует выполнение бизнес-операций
  • Координирует доменные объекты и инфраструктуру
  • Зависит от доменного слоя

• Domain Layer (Ядро бизнес-логики)

  • Содержит сущности, агрегаты, value-объекты, доменные сервисы
  • Определяет интерфейсы репозиториев и внешних сервисов
  • НЕ ЗАВИСИТ от других слоёв

• Infrastructure Layer (Реализации)

  • Реализует интерфейсы доменного слоя
  • Работа с БД, внешними API, кэшем, очередями
  • Зависит от всех внутренних слоёв

Важность правильного направления зависимостей

1. Сохранение независимости бизнес-логики

Доменный слой остаётся неизменным при смене технологий (БД, фреймворка, транспорта данных).

// Домен не знает о способе хранения
class UserService
{
    private UserRepositoryInterface $repository;
    
    public function __construct(UserRepositoryInterface $repository)
    {
        $this->repository = $repository;
    }
    
    // Бизнес-логика не зависит от реализации хранения
}

2. Тестируемость

Внутренние слои можно тестировать изолированно с помощью моков/стабов.

// Юнит-тест доменного сервиса с mock-репозиторием
public function testUserRegistration(): void
{
    $mockRepository = $this->createMock(UserRepositoryInterface::class);
    $service = new UserService($mockRepository);
    
    // Тестируем бизнес-логику без реальной БД
}

3. Гибкость и поддерживаемость

• Легко заменить реализацию (перейти с MySQL на PostgreSQL)
• Упрощается миграция на новые версии фреймворков
• Возможность постепенного рефакторинга

Особенности в контексте микросервисов

В микросервисной архитектуре появляется дополнительное измерение — межсервисные зависимости, которые управляются иначе:

• Слабая связанность между сервисами через API (REST, gRPC, сообщения)
• Каждый сервис инкапсулирует свою доменную логику
• Зависимости от других сервисов реализуются через:
  • Клиенты внешних API (Infrastructure Layer)
  • Асинхронную коммуникацию через брокеры сообщений
  • Pattern Anti-Corruption Layer для защиты домена

Распространённые антипаттерны

1. Нарушение направления зависимостей:

// НЕПРАВИЛЬНО: Домен зависит от инфраструктуры
use Illuminate\Database\Eloquent\Model;

class Order extends Model // Наследование от фреймворка
{
    // Домен теперь привязан к Eloquent ORM
}

1. Смешивание слоёв в одном классе (контроллер, который содержит бизнес-логику и SQL-запросы).

Практические рекомендации

• Используйте Dependency Injection для инверсии зависимостей
• Внедряйте интерфейсы на границах слоёв
• Применяйте DTO (Data Transfer Objects) для передачи данных между слоями
• Используйте события (events) для слабой связанности внутри сервиса

Правильное направление зависимостей — фундаментальный принцип, который делает микросервисы поддерживаемыми, тестируемыми и эволюционируемыми в долгосрочной перспективе.