Как правильно сделать связь 1:M в агрегате при использовании DDD?

Question

[Макс]

Подскажите, как правильно в ORM (например, в Doctrine 2) организовать связь один ко многим в Агрегате (Aggregate) между сущностями.

Возьмем пример: есть Правило (Rule) и Нарушение (Violation).
Очевидно, что Нарушения без Правила быть не может. Rule - это Aggregate Root, т.е. доступаться к Violation мы будем только через Rule.

Вопрос, как правильно тут сделать отношения?
Варианты:

• 1:M Bidirectional, где внешний ключ `rule_id` будет в таблице `violations`.
  
• 1:M Unidirectional через таблицу связку, но в таком случае будут три таблицы: `rules`, `violations`, `rule_violations`.
  

И, самое главное, как будет выглядеть сущность Violation - будем ли мы в конструктор передавать `$ruleId`, или Violation ничего о Rule знать не будет?

Первый вариант

class Violation
{
    public function __construct(ViolationId $vid, RuleId $rid, /* other parameters /*)
}

Второй

class Violation
{
    public function __construct(ViolationId $vid, /* other parameters /*)
}

Если это правильно хранить ruleId в сущности Violation, то как тогда сделать маппинг в ORM, ведь Doctrine работает с объектами отношениями, а не с простыми integer.

Спасибо

Answer 1

[Vicom]

перепишите вопрос на русский, пожалуйста, что за

организовать связь один ко многим в Агрегате

(есть понятие Агрегации, но про Агрегаты я слышу впервые)

доступаться

(песня без слов, ночь без сна..)

..либо я серость и всё это термины из области, о которой я слишком не слышал,
т.к. изначально читаю это и думаю метамоделью UML сразу же

%публика%, растолкуй кто в лес, а кто по дрова, я только проснулся? )

Comments

[Алексей Скобкин]

Тоже ничего не понял. По-моему, автор мыслит в своей предметной области и не умеет объяснять для тех, кто вне её приводя простые аналогии вида "Алиса и Боб".

[Макс]

Хорошо ребята, объясню с другой стороны.

По поводу изначального вопросы: Агрегат - это совокупность сущностей, где есть главная сущность (Aggregate Root), которая управляет всеми другими внутри области "ее действия". Это все понятия DDD *Domain Driven Design". (здесь не Агрегация, а именно Агрегат).

Если забыть про все эти термины, сформулирую вопрос еще раз по-простому:

У меня есть сущность Rule (Правило), есть зависимые от нее сущности Violations (Нарушения правила). Вопрос в том, какой тип связи у них должен быть в рамках Doctrine ORM.

Как я написал выше в исходном вопросе, типов связи может быть как минимум 2 (см.выше).

Мой главный вопрос, как построить маппинг (организовать код сущностей в связке с Doctrine) для отношения Rule <-> Violation, учитывая то, что Violation НЕ должен ничего знать о Rule, но в тоже время нам надо понимать какие Violations относятся к конкретному Rule.

Следуя тенденциям современного написания кода, и толкованиям DDD, сущности инициализируются полным набором данных используя конструктор, т.е. не имеют сеттеров. В связи с этим дополнительный вопрос - должны ли мы иметь `ruleId` внутри сущности Violation и как всё это ложится на мапинг Doctrine

/cc Алексей Скобкин

[Алексей Скобкин]

Макс: Ну, если я правильно понял, при условии, что Violation ничего не знают о Rule при связи ManyToOne от Violation такого сделать не выйдет. Значит можно делать через таблицу-связку, например.

Answer 2

[GrizliK1988]

По поводу настройки Doctrine применительно к DDD можно почитать здесь: https://leanpub.com/ddd-in-php. В целом весьма полезная книга.

Comments

[Макс]

Добрый день. Я ее прочитал, и там такая же проблема. Они мапят foreign key на поле объекта. Более подробно тут https://github.com/dddinphp/last-wishes/issues/16

[GrizliK1988]

Макс: К сожалению, не имею практического опыта решения подобной проблемы касаемо DDD подхода. Можно создать фабрику, которая на входе будет получить данные из доктрины (можно сущности или простой массив) и на выходе вернет AR без ruleId у Violation. Так приложение "отвяжется" от релиционной модели.

Answer 3

[Максим]

Зачем вам interger? Зачем вам в конструктор передовать ID? Это DDD, вы работаете с объектами и их поведением, а не со свойствами объектов.
То есть

<?php
class Violation
{
    private $id;
    private $rules;
    public function __construct(ViolationID $vid, array $rules = []) {
        $this->id = $vid;
        $rules = $rules;
    }
    
    public function addRule(Rule $rule) {
        $this->rules[] = $rule;
        return $this;
    }

    public function deleteRule(Rule $rile)...
    public function getRules()...
    ...
}

class Rule
{
    private $id;
    private $violation;
    public function __construct(RuleID $rid, Violation $violation) {
        $this->id = $rid;
        $this->violation = $violation;
    }
    ...
}

Проблем с маппингом никаких быть не должно, приведу пример в yaml и рекомендую при использовании DDD и доктрины использовать external mapping.

Core\Violation:
  type: entity
  table: violation
  repositoryClass: InfrastructureBundle\Repository\PersistViolationRepository
  oneToMany:
    rules:
      cascade: [ "persist", "remove" ]
      targetEntity: Core\Rule
      mappedBy: violation
      orphanRemoval: true

Core\Rule:
  type: entity
  table: rule
  repositoryClass: InfrastructureBundle\Repository\PersistRuleRepository
  manyToOne:
    violation:
      targetEntity: Core\Violation
      inversedBy: rules
      joinColumn:
        name: violation_id
        referencedColumnName: id

UPD: Я плясал от того что одно нарушение содержит в себе несколько правил. Как я понял у вас наоборот, но сути это не меняет.

Comments

[Макс]

1. наоборот, одно правило содержит несколько нарушений, ну не суть
2. external mapping согласен, только он
3. разве это правильно хранить объекты внутри агрегата, а не айдишники?

возможно вам будет интересен мой вопрос и некоторые ответы отсюда https://github.com/dddinphp/last-wishes/issues/16

[Макс]

Посмотрите по в ссылке на гитхабе, как авторы книги DDD in PHP реализовали User->Wish отношения. Они используют one-to-many through join table И передают UserId в сущность Wish, при это делая мапинг foreign key на проперти объекта.

Вот это и вызывает вопросы и недопонимание

[Максим]

Да вижу. Все равно вопросов с маппингом у вас не должно быть. Вы указываете что поле с IDшником это объект, доктрина дальше сама разберется.
Вопрос про объекты, я пишу в своих проектах на объектах и пока не встречал проблем (единственное наверно, о чем можно задуматься это запросы через Doctrine Proxy, SecondLevelCache). Да, может быть в каких-то случаях есть оверхед на запросе к базе\кешу и гидрации, но я пока его еще не ощущал. В примерах самой доктрины, например, объекты: docs.doctrine-project.org/projects/doctrine-orm/en... Этот вопрос также для меня остается открытым, нужно подумать по этому поводу, но мне кажется управлять объектами проще визуально и лексически правильнее. Вы можете привести какие-либо замечания по поводу объектов?