Собес Гуру

Записываю сюда темы которые стоит изучить и описать, чтобы можно было проще пройти собеседования в компании

Общее

CQRS (Command Query Responsibility Segregation)

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

Основные принципы CQRS:

Разделение моделей: Основной идеей CQRS является разделение модели, которая используется для изменения данных (команды), от модели, которая используется для их чтения (запросы). Это позволяет каждой модели быть оптимизированной под свои задачи, что может включать различия в хранении, поведении и даже в технологии.
Упрощение бизнес-логики: Командная модель может сосредоточиться только на применении бизнес-правил и гарантировании согласованности данных, в то время как модель запросов может быть оптимизирована для быстрого и эффективного извлечения данных.
Независимость масштабирования: Различные требования к производительности и масштабированию для операций чтения и записи могут быть удовлетворены более эффективно, поскольку каждая сторона может быть масштабирована независимо.

Пример применения CQRS:

Представим систему управления заказами в интернет-магазине. В этом случае командная модель отвечает за обработку новых заказов, изменения статуса заказов и управление возвратами. Модель запросов, с другой стороны, используется для отображения списка заказов пользователю, деталей заказа, истории покупок и т. д.

// Пример командной модели
class OrderCommandService {
    public function placeOrder($userData, $productData) {
        $order = new Order();
        $order->create($userData, $productData);
        $order->save();
        // Логика проверки и бизнес-правила
    }

    public function cancelOrder($orderId) {
        $order = Order::find($orderId);
        $order->status = 'cancelled';
        $order->save();
        // Дополнительные действия, например, возврат средств
    }
}

// Пример модели запросов
class OrderQueryService {
    public function getOrderById($orderId) {
        $order = Order::find($orderId);
        return $order->toArray();
    }

    public function getUserOrders($userId) {
        $orders = Order::where('user_id', $userId)->get();
        return $orders->toArray();
    }
}

Преимущества и недостатки CQRS:

Преимущества:

Производительность и масштабируемость: Разные требования к чтению и записи можно удовлетворить более эффективно.
Упрощенная сложная бизнес-логика: Разделение команд и запросов может сделать систему проще для понимания и поддержки.

Недостатки:

Сложность архитектуры: Введение CQRS может усложнить архитектуру системы, особенно в системах, где разделение на команды и запросы не дает значительных преимуществ.
Согласованность данных: Если используются разные источники для команд и запросов, может возникнуть задержка между выполнением команды и обновлением данных, доступных для запросов.

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

DDD (Domain-Driven Design, Проектирование, ориентированное на домен)

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

Основные концепции DDD:

Убедитесь, что разработчики и эксперты домена тесно сотрудничают: Это помогает команде лучше понимать бизнес-процессы и бизнес-правила, что важно для создания эффективной системы.
Разделение на поддомены: DDD предлагает разделение сложной системы на более мелкие, управляемые части, известные как поддомены. Это позволяет специализировать и оптимизировать разные аспекты системы.
Ограниченные контексты (Bounded Contexts): Это центральное понятие в DDD, представляющее логическую границу, в которой определенный домен моделируется с консистентностью и изоляцией от других моделей.
Сущности (Entities) и Значимые Объекты (Value Objects):
- Сущности: Объекты, которые определяются своей идентичностью, а не атрибутами.
- Значимые объекты: Объекты, которые определяются исключительно своими атрибутами и не имеют концептуальной идентичности.
Агрегаты: Коллекция объектов, которые вместе образуют единицу данных и управляются корневой сущностью, известной как корневой агрегат.
Сервисы (Services): Компоненты, которые реализуют доменную логику или бизнес-правила, но не подходят для моделирования в виде сущностей или значимых объектов.
Репозитории и Фабрики (Repositories and Factories):
- Репозитории: Используются для инкапсуляции логики запросов к коллекции агрегатов или сущностей.
- Фабрики: Ответственны за создание сложных объектов и агрегатов, обеспечивая их корректную инициализацию.

Преимущества DDD:

Лучшее понимание бизнеса: Помогает разработчикам и бизнес-аналитикам глубже понять предметную область проекта.
Гибкость и масштабируемость: Подход позволяет системе быть более гибкой и легко масштабируемой за счет четкого разделения и инкапсуляции различных аспектов системы.
Улучшенное сотрудничество: Стимулирует более тесное сотрудничество между разработчиками и специалистами предметной области, что способствует созданию более качественного продукта.

DDD — это мощный инструмент для организации и управления сложными проектами и системами, что делает его популярным выбором в мире программирования, особенно в микросервисных архитектурах.

Четыре основных слоя в DDD:

Презентационный слой (Presentation Layer):
- Отвечает за взаимодействие с пользователем, отображение данных и обработку пользовательского ввода.
Слой приложения (Application Layer):
- Координирует действия пользователя, делегирует задачи слою домена для выполнения бизнес-логики, и организует поток данных в системе и из нее.
Доменный слой (Domain Layer):
- Сердце бизнес-логики приложения. Содержит бизнес-правила, сущности, значение объектов, агрегаты и доменные события. Все изменения в бизнес-логике в первую очередь затрагивают этот слой.
Инфраструктурный слой (Infrastructure Layer):
- Предоставляет техническую поддержку для всех слоев. Включает в себя репозитории, которые инкапсулируют логику доступа к данным, обеспечивая, чтобы доменный слой мог оставаться независимым от деталей реализации хранения данных.

В архитектуре, основанной на Domain-Driven Design (DDD), разные элементы дизайна распределяются по разным слоям согласно их ролям и обязанностям в системе. Вот как обычно они распределяются:

1. Доменный слой (Domain Layer)

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

Сущности (Entities): Это объекты, которые имеют уникальную идентичность, которую можно отслеживать на протяжении их жизненного цикла. Они представляют ключевые бизнес-сущности в домене.
Значимые объекты (Value Objects): Объекты, которые определяются исключительно их атрибутами и не имеют уникальной идентичности. Они описывают характеристики или качества чего-либо и часто используются для измерений или других свойств сущностей.
Агрегаты (Aggregates): Группа сущностей и значимых объектов, которые рассматриваются как единое целое в отношении изменений данных. Агрегаты имеют корневую сущность, известную как агрегатный корень, который контролирует доступ к членам агрегата и гарантирует согласованность.
Доменные события (Domain Events): События, которые значимы в предметной области и могут инициировать другие операции в домене или во внешних системах.