DDD - как регидратации

Question

Вопроса: что является лучшим, эффективным и будущим доказательство способа регидратации агрегата из хранилища? Каковы преимущества и преимущества предоставленных способов и правильное ли мое восприятие?

Допустим, у нас есть агрегатный Root с частными сеттерами, но публичными добытчиками для доступа состояния

Поведения делается с помощью методов на агрегированном корне.

Хранилище дано указание Нагрузка агрегат.

В настоящее время я вижу несколько возможных способов для достижения этой цели: (. Ручной или автоматический, например Automapper)

1. установить состояние через отражение
2. сделать Конструкторы, которые принимают свойства поэтому установлено состояние
3. загрузить агрегат state object

1) Jimmy Bogard указывает, что его инструмент Automapper не предназначен для двустороннего картирования. Но некоторые люди утверждают, что мы должны быть прагматичными, использовать инструменты так, как они вам помогут.

Для меня мне не нравится полный регидратация через отражение. Возможно, Automapper существует, или совокупность корней согнута таким образом, что можно сделать сопоставление (см. Некоторые комментарии Vaughn в его статье).

2) создание конструкторов для регидратации, с несколькими параметрами, чтобы состояние агрегата было регидратировано правильным образом.

Эти пара параметров могут расширяться (= новые конструкторы) или определение может измениться. Мне нравится этот подход, за исключением части наличия множества параметров.

3) состояние является собственностью совокупного корня. Состояние инкапсулируется в новый объект, и этот объект создается репозиторием и затем присваивается корню агрегата для правильного init.

Некоторые люди утверждают, что создание этого объекта состояния работа (новый класс, воздействие свойств объекта на сущность и совокупный корень для обеспечения соблюдения бизнес-правил), но он обеспечивает чистый способ инициализации состояния.

Скажите, что нам нужен источник событий, загружается ли состояние загрузки при загрузке событий? И обеспечивает ли объект состояния способ обработки событий? Является ли это более перспективным доказательством?

Answer 1

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

Это, как говорится, я полностью согласен с тем, что говорит Джимми, поскольку AutoMapper не предназначен для двустороннего картографирования. Ваш домен представляет «правду» в вашем приложении и не должен быть напрямую изменен. Я работал над проектами с двухсторонними сопоставлениями, и, хотя они работают, есть тенденция начать рассматривать объекты домена как не более чем DTO. Это становится болезненным, когда вы начинаете иметь свойства только для чтения, должны задумываться о том, чтобы сделать свою настройку или нет. С точки зрения DDD, мы не должны позволять внешним влияниям просто говорить, какова должна быть стоимость собственности, поскольку это, скорее всего, приведет к модели анемичного домена.

Внутренние штаты работают хорошо, но они стоят за дополнительные накладные расходы и сложность. Как вы говорите, есть законный компромисс в том, что вы добавляете достаточную сумму работы. Однако вы можете использовать эту возможность, чтобы позволить агрегату проверять состояние на соответствие автономным бизнес-правилам в совокупности до того, как разрешено устанавливать состояние. Это касается наибольшей озабоченности, которую я испытываю при двустороннем сопоставлении. Вы можете по крайней мере обеспечить, чтобы объект состояния содержал достоверные данные, а затем строил агрегат только в том случае, если он действителен. Это также более проверяемо. Самая большая проблема, которую я видел при таком подходе, заключается в том, что уровень навыков вашей команды будет иметь прямое отношение к успеху этого использования. Можно утверждать, что сложность не добавляет достаточного значения для реализации всей области, так как вы, вероятно, будете иметь агрегаты, которые имеют разные уровни оттока. Несколько проектов, в которых я участвовал, использовали этот подход, и я нашел мало преимуществ перед использованием прямого конструктора.

Обычно я использую конструкторы для регидратации в большинстве случаев. Он проходит линию между не слишком сложным и не несет ответственности за агрегат, чтобы разрешить или запретить построение объекта - опять же, позволяя домену контролировать, приведет ли попытка гидратации к действительному объекту. Хорошим компромиссом для раздувания конструктора является использование изменчивого DTO в качестве параметра для конструктора, по существу действующего как структура данных для поддержания согласованной сигнатуры конструктора с течением времени. По сути, это также несколько перспективно. Он занимает наиболее привлекательный уровень объектного подхода, который является чистыми сигнатурами, но удаляет дополнительный слой внутренней абстракции.

Вы упомянули о событиях, связанных с возможностью прохода по дороге. Государственная загрузка не очень похожа на то, что вы будете делать, вообще (на мой взгляд). С объектом состояния вы мгновенно снимаете состояние агрегата в определенный момент времени. При использовании источников событий вы будете переигрывать события, каждый из которых представляет данные, необходимые для мутации состояния, в отличие от самого состояния. Таким образом, ваш конструктор, вероятно, будет представлять собой совокупность событий, представляющих цепочку дельт, чтобы повторно мутировать состояние, пока не достигнет текущего состояния. Когда вы хотите увлажнить свой агрегат, вы будете снабжать его событиями, связанными с этим агрегатом, и он воспроизведет их, чтобы перейти в текущее состояние. Это одна из истинных сильных сторон источников событий. Вы заставляете гидратацию ваших объектов домена проходить через бизнес-логику, необходимую для их создания, каждый раз. Учитывая список событий, совокупность будет обеспечивать, чтобы каждое изменение состояния было действительным, применяя событие согласованным образом, независимо от того, применяется ли событие в режиме реального времени или воспроизводится, чтобы перейти в текущее состояние.

Возврат к перспективному аспекту, поскольку он относится к источнику событий, требуется осознанное усилие, необходимое для изменения событий. Поскольку вам нужно воспроизвести событие, чтобы перейти в текущее состояние, вам, скорее всего, придется отказаться от событий и привнести новые события для перехода к изменениям вашей бизнес-логики. Вы можете (читайте как «вероятная воля») найти события для управления версиями. Мало того, что ваш агрегат должен понимать текущие требования к изменению состояния, но он также должен понимать предыдущие требования к изменениям состояния. Таким образом, если вы измените обработчик событий, вы должны будете убедиться, что он будет действителен и для существующих событий.Когда вы добавляете дополнительные данные в событие, это обычно не слишком привлекательно. Но когда вы начинаете удалять данные из сигнатуры события, вы мгновенно делаете это событие под угрозой несовместимости с более ранними структурами. Аналогично, даже изменение имен структур данных внутри события может привести к проблемам обратной совместимости. Если вы начинаете поиск источников событий, вам не нужно беспокоиться о будущей проверке, поскольку вы выполняете обратную совместимость. Приобретение событий велико, но будьте готовы к дополнительной сложности.