Specification pattern

[zelenin]

вообще раз рейтинг юзера, то возвращать рейтинг должен $user->rating(), внутри которого его считает сервис (или захардкодьте ваш способ в методе напрямую).

Вы говорите хранить его в сервисе.

я не гвоорю хранить, я говорю считать.

Но я просто не видел, чтобы в DTOAssembler передавали сервисы и это меня немного смущает

Assembler - это сервис уровня приложения. В сервис вы передаете зависимости?

[sda]

Да передаю.

[samdark]

Опять устраиваем из темы свалку? Давайте уже отдельные вопросы задавать в отдельных темах... а то ведь потом ничего не найти.

[sda]

Sam Dark так я так и не понял как использовать этот паттерн. Например в этой статье паттерн используют, чтобы инкапсулировать бизнес-правила. Получается этот паттерн вообще не для того, чтобы описывать query запросы? Получается все создают много конкретных методов в репозиториях и никто не пытается универсализировать репозиторий к единственному методу find ?

[ElisDN]

Получается все создают много конкретных методов в репозиториях и никто не пытается универсализировать репозиторий к единственному методу find?

На то они и конкретные методы, что по ним всегда понятно, что они делают и где используются. Чтобы легко можно было нужные из них закешировать или как угодно независимо переписать. Думаете, что один метод с сотнями if-ов удобнее?

[zelenin]

Получается все создают много конкретных методов в репозиториях и никто не пытается универсализировать репозиторий к единственному методу find?

На то они и конкретные методы, что по ним всегда понятно, что они делают и где используются. Чтобы легко можно было нужные из них закешировать или как угодно независимо переписать. Думаете, что один метод с сотнями if-ов удобнее?

мы тут как раз if'ы не обсуждали

[ElisDN]

мы тут как раз if'ы не обсуждали

Ну я предположил, что в случае с одним методом они когда-то появятся.

[sda]

ElisDN, zelenin я уже сильно забыл php и sql но я приведу пример, как я вижу сохранение агрегата в базу, вы пожалуйста скажите мне правильно ли я это понимаю или нет. Пусть для упрощения (в целях примера) будет только UPDATE и не будет транзакций. Пусть для упрощения не будет никаких бизнес правил и value objects. Пусть будет Customer, который агрегирует Orders. Пусть они выглядят следующим образом

Код: Выделить всё

//Customer.php

namespace domain;

use domain/Order;

class Customer {
    private $id;
    private $name;
    private $orders = [];
    
    public function __construct($id, $name, $orders) {
        $this->id = $id;
        $this->name = $name;
        $this->orders = $orders;
    }
    public function getId() {
        return $this->id;
    }
    public function getName() {
        return $this->name;
    }
    public function getOrders() {
        return $this->orders;
    }
    public function addOrder(Order $order) {
        $this->orders[] = $order;
    }
}

//Order.php

namespace domain;

class Order {
    private $id;
    private $customerId;
    private $sum;
    
    public function __construct($id, $customerId, $sum) {
        $this->id = $id;
        $this->customerId = $customerId;
        $this->sum = $sum;
    }
    public function getId() {
        return $this->id;
    }
    public function getCustomerId() {
        return $this->customerId ;
    }
    public function getSum() {
        return $this->sum;
    }
}
 

Тогда репозитории могут выглядеть следующим образом

Код: Выделить всё

namespace infrastructure;

use domain\Customer;
use domain\OrderRepositoryInterface;

class CustomerRepository implements \domain\CustomerRepositoryInterface {
    public function __construct(OrderRepositoryInterface $orderRepository) {
        $this->orderRepository = orderRepository;
    }
    ...
    public function add(Customer $customer) {
        $stmt = $pdo->prepare("UPDATE customers SET name = :name WHERE  id = :id");
        $stmt->bindParam(':name', $customer->getName());
        $stmt->bindParam(':name', $customer->getId());
        $stmt->execute();
        
        $orders = $customer->getOrders();
        
        for($i = 0; $i < count($orders); $i++) {
            $this->orderRepository->add($orders[$i]);
        }
    }
}

namespace infrasturcture;

use domain\Order;

class OrderRepository implements \domain\OrderRepositoryInterface {
    ...
    public function add(Order $order) {
        $stmt = $pdo->prepare("UPDATE orders SET sum = :sum, customer_id = :customer_id WHERE id = :id");
        $stmt->bindParam(':sum', $order->getSum());
        $stmt->bindParam(':customer_id', $order->getCustomerId());
        $stmt->bindParam(':id', $order->getId());
        $stmt->execute();
    }
}
 

Затем клиент вызывает $this->customerRepository->add($customer); и данные в нужных таблицах изменяются. Примерно так должно быть организовано хранение сущностей в базе? Я понимаю, что здесь есть проблема множества запросов к базе, но мне несущественно, так как я не использую рсубд, мне интересно в целом верно ли я понимаю концепцию?

[zelenin]

ну примерно так и есть

[zelenin]

кстати в книге Applying DDD and Patterns Джимми Нильссона в части, касаемой репозиториев и запросов в них, описывается один в один вариант, который я предложил: использование Query в качестве элемента доменного слоя (абстракция над запросом в репо) и метод getQuery репозитория, принимающий запрос в виде объекта Query, итогом чего становится единый и гибкий язык запросов домена.