Какеи преимущества слоистых (многоуровневых) архитектур?

Слоистая (многоуровневая) архитектура

Слоистая архитектура (Layered Architecture) — это организация приложения в горизонтальные слои, где каждый слой отвечает за одну функцию и зависимости идут только вниз (от верхних к нижним).

Типичная структура

Presentation Layer (Контроллеры, Views, API)
         |
 Application Layer (Use Cases, Services)
         |
Domain Layer (Бизнес-логика, Entities)
         |
Infrastructure Layer (БД, HTTP, Email)

Преимущества слоистой архитектуры

1. Разделение ответственности (Separation of Concerns)

// Presentation Layer
Route::post('/users', [UserController::class, 'store']);

// Application Layer
class UserService {
    public function create($data) {
        $this->validate($data);
        return $this->repository->save($data);
    }
}

// Domain Layer
class User {
    private $email;
    private $password;
    
    public function __construct($email, $password) {
        $this->email = $email;
        $this->password = password_hash($password);
    }
}

// Infrastructure Layer
class UserRepository {
    public function save(User $user) {
        DB::table('users')->insert(...);
    }
}

// Каждый слой знает только свою работу

2. Переиспользование кода

• Application Layer код используется в Controllers, CLI Commands, API
• Domain Logic переиспользуется везде
• Infrastructure слой изолирован

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

// Легко тестировать каждый слой отдельно

// Unit тест Application Layer
class UserServiceTest extends TestCase {
    public function test_creates_user_with_valid_data() {
        $repository = Mockery::mock(UserRepository::class);
        $service = new UserService($repository);
        
        $repository->shouldReceive('save')->once();
        $service->create(['email' => 'test@example.com', 'password' => 'pass']);
    }
}

// Domain Layer не зависит от БД
class UserTest extends TestCase {
    public function test_user_password_hashed() {
        $user = new User('test@example.com', 'password');
        $this->assertTrue(password_verify('password', $user->getPassword()));
    }
}

4. Поддержка и изменения

• Изменения в БД не влияют на бизнес-логику
• Добавление нового API (GraphQL) не требует изменения Domain
• Миграция на другую БД проще

// Меняем только Infrastructure Layer
// Domain и Application не меняются

// Было: MySQL
class MySQLUserRepository implements UserRepository { }

// Стало: PostgreSQL
class PostgreSQLUserRepository implements UserRepository { }

// Бизнес-логика (Application + Domain) остаётся той же

5. Масштабируемость команды

• Разные люди работают на разных слоях
• Frontend разработчик работает с Presentation
• Backend разработчик с Application
• Database специалист с Infrastructure
• Меньше конфликтов слияния кода

6. Безопасность

// Infrastructure слой содержит credentials
// Domain слой о них ничего не знает
// Секреты локализованы в одном месте

class UserRepository {
    private $db; // Secret connection
    
    public function save(User $user) {
        // Только этот слой работает с БД
    }
}

7. Миграция и рефакторинг

// Переход с одного фреймворка на другой
// Domain и Application слои остаются те же
// Меняется только Presentation и Infrastructure

// Было: Laravel
Route::post('/users', [UserController::class, 'store']);

// Стало: Slim
$app->post('/users', [UserController::class, 'store']);

// Controllers и Services остаются те же

Пример структуры проекта

src/
├── Domain/
│   ├── User.php
│   ├── Order.php
│   └── UserRepository.php (интерфейс!)
├── Application/
│   ├── CreateUserService.php
│   ├── RegisterUserUseCase.php
│   └── UserDTO.php
├── Infrastructure/
│   ├── Persistence/
│   │   ├── EloquentUserRepository.php
│   │   └── UserMapper.php
│   ├── API/
│   │   └── ExternalPaymentService.php
│   └── Email/
│       └── SMTPMailer.php
└── Presentation/
    ├── HTTP/
    │   ├── Controllers/
    │   └── Routes
    ├── CLI/
    │   └── Commands
    └── API/
        └── Resources

Правило зависимостей

Presentation → Application → Domain
    ↓              ↓           ↓
Infrastructure ← Infrastructure ← Infrastructure

Представление зависит от Application
Application зависит от Domain
Domain зависит от Infrastructure (через интерфейсы)
Инфраструктура НЕ зависит от ничего выше

Недостатки (важно знать)

• Overhead для простых проектов — может быть переусложнением
• More boilerplate code — больше файлов и кода
• Обучение кривая — разработчики должны понимать архитектуру

Когда использовать

✅ Используй если:

• Большой проект
• Много разработчиков
• Требования часто меняются
• Нужна тестируемость

❌ Не используй если:

• CRUD приложение
• MVP стартап
• Очень простая логика
• Один разработчик

Вывод

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