В примерах по DDD везде пишут геттеры для доступа к свойствам агрегата, но если свойство является сущностью, то ничего не мешает вызвать метод этой дочерней сущности за пределами агрегата, чего нельзя делать. Это как-то запрещается на уровне кода? Или это просто соглашение в мире DDD, что нельзя вызывать методы дочерней сущности агрегата за его пределами, но по факту внутренности торчат наружу?
Тоже самое спрашивают здесь http://stackoverflow.com/questions/1080 ... ild-entity
Как ограничить доступ к методам дочерних сущностей агрегата?
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
почему нельзя?sda писал(а):В примерах по DDD везде пишут геттеры для доступа к свойствам агрегата, но если свойство является сущностью, то ничего не мешает вызвать метод этой дочерней сущности за пределами агрегата, чего нельзя делать.
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
Если переживаете за инвариант агрегата, то не пишите геттеры, возвращающие саму сущность. Тогда и будет защита от внешних изменений на уровне кода.sda писал(а):...пишут геттеры для доступа к свойствам агрегата, но если свойство является сущностью, то ничего не мешает вызвать метод этой дочерней сущности за пределами агрегата, чего нельзя делать. Это как-то запрещается на уровне кода?
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
Да переживаю за инвариант. Но мне требуются поля этой дочерней сущности, чтобы потом собрать DTO и отправить в клиент. То есть мне нужно состояние этой дочерней сущности, но в то же время я не хочу, чтобы её методы торчали наружу. Как это решается в мире DDD ?ElisDN писал(а):Если переживаете за инвариант агрегата, то не пишите геттеры, возвращающие саму сущность. Тогда и будет защита от внешних изменений на уровне кода.sda писал(а):...пишут геттеры для доступа к свойствам агрегата, но если свойство является сущностью, то ничего не мешает вызвать метод этой дочерней сущности за пределами агрегата, чего нельзя делать. Это как-то запрещается на уровне кода?
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
В книгах по ddd так пишут, что вся работа с дочерними сущностями должна идти через корень агрегата, чтобы соблюдались все инварианты и никогда не вызывать из вне агрегата дочерние сущности.zelenin писал(а):почему нельзя?sda писал(а):В примерах по DDD везде пишут геттеры для доступа к свойствам агрегата, но если свойство является сущностью, то ничего не мешает вызвать метод этой дочерней сущности за пределами агрегата, чего нельзя делать.
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
а, я не так понял.
Вы имеете в виду такую ситуацию:
$address = $user->getAddress();
$address->setNewStreet(...);
если да, то никак. это элемент архитектуры, то есть устного соглашения, как и "не использовать прямой коннекшн в базу вместо репозитория" - прямой конннекшн тоже можно заюзать без ограничения.
Вы имеете в виду такую ситуацию:
$address = $user->getAddress();
$address->setNewStreet(...);
если да, то никак. это элемент архитектуры, то есть устного соглашения, как и "не использовать прямой коннекшн в базу вместо репозитория" - прямой конннекшн тоже можно заюзать без ограничения.
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
Да, я имею ввиду именно такую ситуацию. В книгах по ddd этому уделяется настолько значительный объем внимания, что складывается впечатление, что это что-то очень важное. Поэтому я и подумал, что может быть в ddd существует определенное решение. В гугле совершенно не удалось найти никакого проявления интереса к этой проблеме. Возникает когнитивный диссонанс из-за логического несоответствия. Не выглядит чем-то настолько важным в реальности, как это описано в книгах.
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
setNewStreet(...); просто не надо помещать в $address, это должно быть в билдере $userBulder->setNewStreet($user,$address); Так и ограничиваем.
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
Вы не можете все методы реализующие ту или иную логику дочерней сущности поместить в билдер или куда-то еще. В дочерней сущности в любом случае будут какие-то методы. И они будут торчать наружу. В этом проблема.
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
Если они критичны в философском вопросе, то помещаем их в отдельный класс, который будет ответственен за определённую задачу.
Остальное не критичное - пусть торчит. Не выдумывайте проблем на пустом месте. Если кто-то начнёт активно использовать "неправильно" эти методы и при этом проект станет не гибким, трудно изменяемым, то вот тогда и появится проблема, которая решается через паттерн Private class или его производные...
Остальное не критичное - пусть торчит. Не выдумывайте проблем на пустом месте. Если кто-то начнёт активно использовать "неправильно" эти методы и при этом проект станет не гибким, трудно изменяемым, то вот тогда и появится проблема, которая решается через паттерн Private class или его производные...
Re: Как ограничить доступ к методам дочерних сущностей агрегата?
Проект станет неверно работающим.Если кто-то начнёт активно использовать "неправильно" эти методы и при этом проект станет не гибким
Судя по описанию паттерна здесь https://en.wikipedia.org/wiki/Private_c ... ta_pattern он не подходит.решается через паттерн Private class или его производные...
Я не хочу забирать привилегию записи аттрибутов после создания объекта, тем более у методов целевого класса. Задача другая.It allows the class designer to remove write privilege of attributes that are intended to be set only during construction, even from methods of the target class.