Действительная модель домена при использовании Automapper

Question

Я использую прекрасный автомат Jimmy Bogard для сопоставления моей модели API с классами POCO (модель домена). Модель API не содержит определенных атрибутов модели домена, которые необходимы для правильной работы модели домена. В этом случае, когда Automapper завершает свое задание, у меня есть полностью построенная модель домена в недопустимом состоянии. Не использовать Automapper не вариант, потому что слишком много атрибутов для кода руки.

Итак, вот мой вопрос:

Как использовать automapper создать объект таким образом, оставляя модель предметной области в допустимом состоянии.

Благодаря

Answer 1

Я проверить модель API перед тем он получает отображается в моей модели домена, правильно ли я с помощью AutoMapper или нет. Модель API представляет собой команду или действие, поэтому я проверяю команду перед тем, как применить ее к своей сущности, а не мутировать мой объект, а затем попытаюсь проверить его впоследствии. Это также означает, что все мои атрибуты проверки находятся на моей модели API.

Answer 2

Это, вероятно, слишком долго для комментария:

Хотя ответ Джимми правильно это может означает, что ваш проект не может быть столь же инкапсулированный, как это могло быть, так как вы будете иметь, чтобы выставить много государство. Возможно, поэтому есть комментарии вокруг «анемичных» моделей и «не подходят для цели».

Если вы сосредоточены на поведение, то вы можете иметь что-то, совершенно гипотетический, как следует, чтобы сделать ваш клиенту Gold клиент:

customer.MakeGold(); 

Однако, используя состояние вы бы сейчас выставить атрибуты, позвоните на карту Gold. Внутренне ваш клиент, возможно, проверил определенное другое состояние, чтобы определить действительность статуса Gold, тогда как срок действия чек теперь переведен из домена так, как Джимми говорит, что он уверен, что состояние правильное, прежде чем передать его в домен.

Это не столько проблема авто-картона, сколько проблема дизайна. Это также указывает на то, что ваша модель API/Интеграция может быть более ориентированной на данные.

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

// map my APIActivationDetails to Activate --- however automapper does this :) 

var activate = AutoMapper.Map<Activate>().From(apiActivationDetails); 

customer.Activate(activate); 

Давай думать об этом ... это, кажется, что говорит Джимми: P

Answer 3

«чтобы отобразить мою модель API для классов POCO (модели предметной области)»

Почему бы вам когда-нибудь хотите отобразить объект команды (вы r API) атрибуты для объектов домена? Если это то, к чему вы стремитесь, вы, скорее всего, получите чрезмерно спроектированный CRUD, но, конечно, не решение DDD.

Поведение должно быть явно объявлено в агрегатах, и агрегаты несут ответственность за изменение собственного внутреннего состояния в соответствии с защищенными бизнес-инвариантами.

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

Вам не следует пытаться заталкивать данные в агрегаты, вместо этого вы должны попросить их выполнить задачу.