除了加快开发和重用代码之外，还有什么理由让意见 1) 比意见 2) 更受欢迎.

Are there any reasons opinion 1) would be preferred to opinion 2) other than speeding up development and reusing code.

选项1只是因为纯粹的懒惰和想象的提高开发速度.确实，这些应用程序将更快地构建到 1.0 版.但是，当这些开发人员到达应用程序的 3.0 版本时，他们认为维护应用程序没有那么有趣，因为他们不得不在域模型中因 ORM 映射器而做出所有妥协.

Option 1 is just because of pure laziness and imagined increased development speed. It's true that those applications will get version 1.0 built faster. But when those developers reach version 3.0 of the application, they do not think it's so fun to maintain the application due to all compromises that they have had to do in the domain model due to the ORM mapper.

我的模型映射方法有什么问题吗?当解决方案增长时，我是否遗漏了什么会带来问题?

Are there any issues in my approach of mapping the models? Is there something I missed that would bring up issues when a solution grows?

是的.存储库应该负责隐藏持久化机制.它的 API 应该只适用于域实体而不是持久性实体.

Yes. The repository should be responsible of hiding the persistence mechanism. It's API should only work with domain entities and not persistence entities.

存储库负责在域实体之间进行转换(以便能够持久化它们).fetch 方法通常使用 ADO.NET 或类似实体框架的 ORM 来加载数据库对象/实体.然后将其转换为正确的业务实体并最终返回.

The repository is responsible of doing conversions to/from domain entities (to be able to persist them). A fetch method typically uses ADO.NET or an ORM like Entity Framework to load the database object/entity. Then convert it to the correct business entity and finally return it.

否则，您将强制每个服务了解有关持久性和使用域模型的知识，从而有两个责任.

Otherwise you would force every service to have knowledge about persistence AND working with your domain model, thus having two responsibilities.

如果您根据 DDD 定义使用应用程序服务，您可能需要查看命令/查询分离模式，它可以替代应用程序服务.代码变得更清晰，而且您还获得了一个更轻量级的 API，用于包装您的域模型.

If you work with application services per the DDD definition you will probably want to look at the Command/Query separation pattern which can be a replacement of the application services. The code gets cleaner and you also get a much more lightweight API wrapping your domain model.