Тогда тебе придётся что-то делать с именованными конструкторами: Article::begin(). Они возвращают инстанс сущности, но при этом сама сущность уже может содержать события.
Когда тебе понадобится передать вместе с событием ещё какие-то данные, то ты не сможешь это сделать.
ну можно еще типа call_user_function([Article, begin])
можно тоже, но изврат еще тот
Я не понял. Зачем тут call_user_function?
// entity
return [[Article::class, begin]];
//service причем это можно еще раз обернуть и дальше вернуть в конструктор или откуда это началось
foreach( $order->cancel as $event){
return is_array($event) && callable($event) ? call_user_function($event, $id):new $event($id);
}У тебя есть способность превращать простую идею в невероятно сложную.
те. осознаю глупость затеи
агрегату дали выполнить действие. и он порождает события. если ему надо в это время что-то поменять внутри себя - он меняет. ему события для этого не нужны.
То есть все агрегаты должны содержать только уникальный и не повторяющийся код и расширение агрегатов может происходить только путём изменения кода в них?
«Агрегат» — это просто сущность, в большинстве случаев она достаточно небольшая и «плоская» (нет вложенных сущностей), поэтому реиспользование кода решается просто через приватные методы.
В целом — да, сущности изолированы от внешнего мира, поэтому чтобы изменить поведение сущности, нужно изменить её код.
В случае сложных aggregate root необходимость в каком-то внутреннем механизме событий действительно может появится. Например, есть Игра, внутри есть Игроки (вложенные сущности), и действие какого-то Игрока может привести к его проигрышу. Тогда, вероятно, нам захочется удалить этого игрока из Игры. То есть, на основе внутреннего поведения вложенной сущности Игрок мы хотим также сделать изменение в Игре. Технически, решение найти можно, просто все те подходы, которые мне приходили в голову, выглядят так себе. Я не хочу сейчас это подробно расписывать, поскольку красивых решений среди них нет, а на практике я таких aggregate root не встречал.
ну вот еще и open/closed principle
меня реально смущает добавлять/удалять позицию заказа через событие.
Это не имеет отношения к OCP.
Вроде бы мы говорили просто про события, которые ты опционально пишешь, если тебе нужно, а не про event sourcing.
возникает вопрос: имеет ли смысл "позиции заказа" вырезать из "заказа"?
/**
* не плоская сущность
*/
class Order{
/**
* OrderItem[]
*/
private $items;
}$repo->getOrderById($order_id)->addItem( new OrderItem(...));
$repo->store($order);В оригинальном посте что-то было из предметной области (что-то про склад), это меня и смутило.
Нет, конечно, я говорил про большинство случаев, твой «заказ» просто к ним не относится.
В основном, всё упирается в вычислительные ресурсы. Изменения в AR происходят через эксклюзивную блокировку и всё содержимое AR находится в памяти. Следовательно, если будет много параллельных изменений или если будет слишком много данных, то это будет неудачный AR. Например, очевидно, что если ты пилишь issue tracker а-ля Jira/redmine/trac, то делать aggregate root Project со списком всех Issue в нём — это не круто. Этот список Issue потенциально бесконечный. Это достаточно скоро просто перестанет работать. Но это вряд ли касается заказа, здесь скорее всего будет мало параллельных изменений, если они вообще будут; позиций заказа тоже вряд ли будет так много, что у тебя начнутся проблемы с нехваткой памяти.
По моему, тут немного другая причина. Почти все операции будут с issues. И агрегат Project стал бы "завистливым" классом, в основном вызывающим методы у issue. Агрегат же Заказ - вполне себе важная единица и операции в основном идут с ним.
Рассуждая про технические ограничения, я забыл упомянуть самый важный момент, что в aggregate root должны быть только те данные, что необходимы для транзакционных изменений, т.е. для игры это очевидно: некоторые действия затрагивают сразу всех игроков одновременно (например, все платят какому-то игроку; или какой-то игрок проигрывает после действия другого игрока), поэтому тут требуется обеспечить транзакционную целостность действий в игре. По крайней мере, это справедливо для большинства настольных и карточных игр.
Почти все операции агрегата Проект будут doSomethingWithIssue(issueId, params).
Я понял, что ты хочешь сказать, но я не понял в чём тут проблема.
Тут речь про поля/данные, как если бы Project напрямую их менял у Issue, т.е. речь про нарушение инкапсуляции. Но ведь Project совсем не обязан менять поля напрямую. Как это относится к данному случаю?