我正在使用 Jimmy Bogard 的可爱 Automapper 将我的 API 模型映射到 POCO 类（域模型）。 API 模型不包含域模型的某些属性，这些属性是域模型处于有效状态所必需的。在这种情况下，当 Automapper 完成其工作时，我有一个处于无效状态的完全构造的域模型。 不使用 Automapper 不是一种选择，因为要手动编写代码的属性太多。
所以，这是我的问题：
如何使用 automapper 以这种方式创建对象，同时使域模型保持有效状态。
谢谢
【问题讨论】：
标签： domain-driven-design automapper domain-model
评论可能太长了：
虽然 Jimmy 的回答是正确的，但它可能暗示您的设计可能没有像它可能的那样封装，因为您将不得不公开很多状态。这可能就是为什么有围绕“贫血”模型和“不适合目的”的 cmets。
如果您专注于行为，那么您可能有一些完全假设的东西，如下所示，让您的客户成为黄金客户：
customer.MakeGold();
但是，使用状态您现在必须公开允许您映射到 Gold 状态的属性。在内部，您的客户可能已经检查了某些其他状态以确定 Gold 状态的有效性，而该 validity 检查现在已移出域，就像 Jimmy 所说的那样，他确保在将状态传递给域之前，状态是正确的。
这与其说是自动映射器问题，不如说是设计问题。这似乎也表明您的 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 模型上。
【讨论】：