Yii Framework

zelenin, я могу каждое действие пользователя на сайте сохранять как событие в хранилище, а затем если в момент обработки события произошла ошибка, то перенакатить это событие заново. Но тогда наверное события должны быть детерминированными (однозначными), т.е. хранить окончательное значение, вместо ...

zelenin, у меня так и есть. Две разные сущности User и Player. Но Player это самостоятельный агрегат, а не дочерняя сущность агрегата Game, так как нет никаких инвариантов, которые нужно было бы поддерживать между ними. Все что Player знает о Game, это его id. И я не могу засунуть Player в Game. Вон...

zelenin, я не понимаю. НанесенУдар - затрагивает 2 разных агрегата (на самом деле еще больше). Одному агрегату нужно добавить опыта, другому агрегату нужно вычесть жизни. DDD говорит о том, что не следует сохранять более одного агрегата за раз и что для таких кейсов следует пользоваться EC. Я не пон...

Используется nosql. Транзакций нет. Нужно изменить состояние у 3 агрегатов. Есть решение?

Про этот алгоритм транзакций я читал. Это скорее хак, чем решение. Ревью этого решения из компетентных людей никто не делал. Много писали про nosql и eventual consistency, но при этом я не могу найти ни одного примера под nosql. Вот это удивляет. CAS поддерживают не все nosql, следовательно это не у...

1. Что именно неясно в NoSQL? В монго атомарность гарантируется на уровне документа. Мы не можем атомарно добавить документы в несколько коллекций (таблиц в контексте sql). Даже в одну коллекцию не можем атомарно добавить 2 и более документа. 2. Даже если это и polling, то он тоже позволяет добитьс...

rugabarbo, прочитал предложенную вами статью. Под sql примерно понятно как делать, под nosql нет. Также я из примеров не понял, кто и как вызывает EventForwarderService::ForwardEvents() ? Если это простой поллинг базы раз в N времени, то это печальное решение. Есть еще замечания к такой реализации, ...

Но мне не нужны транзакции. Мне нужно реализовать надежный eventual consistency.

В книгах по ddd пишут, что желательно сохранять только 1 агрегат в транзакции. Если агрегат требует, чтобы родственные ему агрегаты тоже как-то изменили своё состояние, то предлагают использовать eventual consistency при помощи domain events. Мне это понятно. У меня вопрос касательно инфраструктуры....

ElisDN я понял так, что вложенные сущности нужны только когда необходимо соблюсти инвариант Отрывок из книги Вон Вернона Implementing Domain-driven design An invariant is a business rule that must always be consistent. There are different kinds of consistency. One is transactional consistency, which...

zelenin я думал, что ответ будет, что нет смысла делать сущность дочерней, если не требуется соблюдать инварианты или что-то такое. Ведь именно этим объясняется необходимость в агрегате в книгах по ddd.

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

Я дополнил вопрос.

Если возникает желание обратиться к конкретному элементу массива $this->orders за пределами Customer, то означает ли это, что Order должен быть самостоятельным агрегатом ? Как вообще понять, когда использовать дочернюю сущность внутри агрегата, а когда ссылаться на другой агрегат по id ? У меня проб...

Не совсем понятно, что конкретно нужно. Вас архитектура приложения интересует или что?

Платформа node.js это v8 и набор модулей на C++ с api в стиле javascript. Поэтому если знать javascript, то достаточно посмотреть api всех этих модулей, чтобы понять что платформа может и как пользоваться. Но если ступор, то можно посмотреть скринкаст Кантора https://www.youtube.com/playlist?list=PL...

class ContactBuilder {     public function withCity($city) {         $this->city = $city;         return $this;     }     public function withAddress($address) {...}     public function withPhone($phone) {...}     public function withFax($fax) {...}     public function withEmail($email) {...}     p...

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

zelenin, меня смущает что dto это application layer. Если я буду dto передавать в метод агрегата, то домен будет зависеть от application layer.

Но что делать если нам для создания объекта Order требуется не 3 параметра, а 10? Какое тогда может быть решение? http://yiiframework.ru/forum/viewtopic.php?f=34&t=36725&p=192540#p192540 10 просто для примера. Вообще это не существенно 4,5,7 или 10. В вашем примере конструктор Contact прини...