Какие принял ключевые решения при проектировании архитектуры?

Ключевые архитектурные решения в проектировании PHP Backend

При проектировании архитектуры PHP-проектов я фокусируюсь на масштабируемости, поддерживаемости и безопасности. Вот ключевые решения, которые я принимаю на основе 10+ лет опыта:

1. Выбор паттерна архитектуры приложения

Я предпочитаю многослойную архитектуру с четким разделением ответственности:

// Пример структуры с Domain-Driven Design элементами
src/
├── Domain/           // Бизнес-логика и сущности
│   ├── Entities/
│   ├── ValueObjects/
│   └── Services/
├── Application/      // Сценарии использования
│   ├── UseCases/
│   └── DTOs/
├── Infrastructure/   // Внешние зависимости
│   ├── Persistence/
│   ├── ExternalAPIs/
│   └── Messaging/
└── Presentation/     // Контроллеры и HTTP-слой
    ├── Controllers/
    ├── Middleware/
    └── Responses/

Решение: Отказ от классического MVC в пользу гексагональной архитектуры (порты и адаптеры) для изоляции бизнес-логики от инфраструктурных деталей.

2. Организация бизнес-логики

Ключевое решение — строгое соблюдение принципа единственной ответственности (SRP):

// Вместо "жирных" моделей ActiveRecord
class OrderService
{
    public function __construct(
        private OrderRepositoryInterface $repository,
        private PaymentGatewayInterface $paymentGateway,
        private EventDispatcherInterface $dispatcher
    ) {}
    
    public function createOrder(CreateOrderDTO $dto): Order
    {
        // Валидация бизнес-правил
        $this->validateOrder($dto);
        
        // Создание сущности
        $order = Order::create($dto);
        
        // Сохранение
        $this->repository->save($order);
        
        // Побочные эффекты через события
        $this->dispatcher->dispatch(new OrderCreated($order));
        
        return $order;
    }
}

3. Работа с данными и персистентностью

Решение: Использование Data Mapper вместо ActiveRecord для разделения модели данных и логики сохранения:

interface UserRepositoryInterface
{
    public function findById(UserId $id): ?User;
    public function save(User $user): void;
    public function findByCriteria(UserSpecification $spec): Collection;
}

class DoctrineUserRepository implements UserRepositoryInterface
{
    // Реализация с использованием Doctrine ORM
}

Дополнительные решения:

• CQRS для разделения операций чтения и записи в высоконагруженных системах
• Репозитории с критериями вместо методов findByX для избежания взрывающегося интерфейса
• Миграции БД как код с инструментами типа Doctrine Migrations

4. Обработка зависимостей

Решение: Внедрение Dependency Injection через контейнер:

// Конфигурация в формате PHP или YAML
services:
  App\Domain\Service\OrderService:
    arguments:
      $repository: '@App\Infrastructure\Persistence\OrderRepository'
      $dispatcher: '@Symfony\Component\EventDispatcher\EventDispatcher'
      
  App\Infrastructure\Persistence\OrderRepository:
    arguments:
      $entityManager: '@Doctrine\ORM\EntityManager'

5. Обработка ошибок и мониторинг

Решение: Единая стратегия обработки исключений с преобразованием в структурированные ответы:

class ErrorHandlerMiddleware
{
    public function process(Request $request, RequestHandler $handler): Response
    {
        try {
            return $handler->handle($request);
        } catch (DomainException $e) {
            // Бизнес-ошибки -> 400 Bad Request
            return new JsonResponse(['error' => $e->getMessage()], 400);
        } catch (NotFoundException $e) {
            // Не найдено -> 404
            return new JsonResponse(['error' => 'Resource not found'], 404);
        } catch (Throwable $e) {
            // Неожиданные ошибки -> 500 с логированием
            $this->logger->error($e->getMessage(), ['exception' => $e]);
            return new JsonResponse(['error' => 'Internal server error'], 500);
        }
    }
}

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

Решение: Проектирование с акцентом на unit-тестирование:

• Все зависимости инжектятся через интерфейсы
• Использование моков и стабов в тестах
• Отделение инфраструктурного кода от бизнес-логики

class OrderServiceTest extends TestCase
{
    public function testCreateOrder(): void
    {
        // Мок-объекты
        $repository = $this->createMock(OrderRepositoryInterface::class);
        $dispatcher = $this->createMock(EventDispatcherInterface::class);
        
        $service = new OrderService($repository, $dispatcher);
        
        // Тестирование чистой бизнес-логики
        $order = $service->createOrder(new CreateOrderDTO(...));
        
        $this->assertInstanceOf(Order::class, $order);
        $this->assertEquals('pending', $order->getStatus());
    }
}

7. Конфигурация и окружения

Решение: 12-факторное приложение с внешней конфигурацией:

// .env файл для переменных окружения
DATABASE_URL=mysql://user:password@localhost:3306/db_name
REDIS_URL=redis://localhost:6379
API_KEY=${API_KEY}

// Чтение конфигурации
$databaseUrl = getenv('DATABASE_URL');
$redisUrl = getenv('REDIS_URL', 'redis://default:6379'); // Значение по умолчанию

Критерии принятия решений

1. Предсказуемость — код должен вести себя одинаково в разных окружениях
2. Тестируемость — каждый компонент должен быть изолированно протестирован
3. Масштабируемость — архитектура должна позволять горизонтальное масштабирование
4. Поддерживаемость — новый разработчик должен быстро разобраться в структуре
5. Производительность — минимальные накладные расходы на абстракции

Эти решения позволяют создавать системы, которые остаются поддерживаемыми при росте команды и функциональности, обеспечивают стабильность в production и позволяют быстро итерировать без накопления технического долга.