Имейте в виду, что Майк Могосану использует подход с использованием источников событий, но в любом случае (без ES) он очень хорош, чтобы избежать нежелательных артефактов в основных языках ООП.
- Какможет ли быть так, что функция является AR, если для нее должен быть глобальный уникальный идентификатор, а причина не в том, что она является функцией. что имеет глобальный уникальный идентификатор, так это событие домена, которое генерирует эта функция.
TransferNumber действует как естественный уникальный идентификатор;в некоторых случаях есть GUID, чтобы избежать необходимости в полном объекте значения.
В памяти компьютера нет уникального состояния идентификатора, потому что это аргумент, но подумайте об этом;почему вы хотите глобальный уникальный идентификатор? Это просто для того, чтобы найти корневой элемент и его дочерние элементы (неуникальный идентификатор) для постоянных целей (найти, изменить или удалить его).
Порядок A имеет 2 строки заказа (1 и 2), в то время как Порядок B имеет 4строки заказа (1,2,3,4);уникальный идентификатор строк заказа представляет собой композицию его идентификатора и идентификатора заказа: A1, B3 и т. д. Он похож на реляционные схемы в реляционных базах данных.
Таким образом, этот идентификатор нужен только для сохранения и элементапостоянство - это доменное событие, выражающее изменения;все изменения, необходимые для обеспечения согласованности, поэтому, если вы сохраните событие домена, используя глобальный уникальный идентификатор, чтобы найти в постоянном состоянии то, что вы должны изменить, система будет в согласованном состоянии.
Вы можете сделать
var newTransfer = New Transfer(TransferNumber); //newTransfer is now an AG with a global unique ID
var changes = t.RegisterTransfer(Debit debit, Credit credit)
persistence.applyChanges(changes);
но какой смысл создавать объект для создания состояния в памяти компьютера, если вы не собираетесь делать с этим объектом более одной вещи? Это бессмысленно, и большинство недоброжелателей ООП используют этот вид плохой ООП-структуры, чтобы критиковать ООП и склоняться к функциональному программированию.
Следующий вопрос - как выглядит Aggregate Root в коде? это событие? это сущность, которая возвращается? это функция самого класса Aggregate?
Это сама функция. Вы можете прочитать в посте:
AR - это роль, а функция - это реализация.
Агрегат представляет собой единицу работы, то есть он долженбыть последовательным. Вы можете увидеть, как функция выполняет это. Это единица работы, которая поддерживает систему в согласованном состоянии.
В случае, если Событием Домена, которое возвращает функция, является AR (как указано, что он должен иметь этот глобальный уникальный идентификатор), то как мы можем взаимодействовать с этим Агрегатом? В первой статье четко указывалось, что все взаимодействие с Агрегатом осуществляется AR, если AR является событием, то мы ничего не можем сделать, кроме как реагировать на него.
Ответил выше, потому что доменсобытие не является AR.
4 Правильно ли говорить, что у агрегата есть два основных задания: применить необходимые изменения на основе полученных данных и правил, которые он знает, вернуть необходимые данные, которые необходимо сохранить. от AR и / или должны быть подняты в событии домена от AR
Да;опять же, вы можете увидеть, как статическая функция выполняет это.
Вы можете попытаться указать Mike Mogosanu . Я уверен, что он мог бы объяснить свой подход лучше, чем я.