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

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

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

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

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

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

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

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

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

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

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