为了让您快速了解我的应用程序架构，我的应用程序中包含以下层：
现在的问题是Web API后来出现了; MVC Web应用程序是第一个构建在架构之上的东西。
我发现自己必须复制业务逻辑和ViewModels（MVC）和消息（Web API）......根据DRY原则，我不应该这样做，所以自然的解决方案是将业务逻辑推入它自己的层，独立于应用层。
但是......这意味着业务逻辑层需要它自己的一组模型，它们位于应用层和业务逻辑层之间。在这方面，它不适用于使用域模型，因为它们实际上不应该到达应用层。
简而言之，我正在寻找业界公认的业务逻辑建模标准。是否有一个公认的标准应该如何工作，如果是，那么什么类型的模型（即它不是域模型，它不是视图模型）属于业务逻辑层？
答案 0 :(得分：1)
你偶然发现了一个有争议的讨论点。我自己一直在努力解决这个问题。
对象偏执者会争辩说你甚至不应该有服务层。然后可以直接使用您的域模型，这将消除逻辑重复。当然，那些是软件建模的美好时光。随着网络，apis和SOA的出现，我们不得不寻找替代方法来建模我们的软件。输入 Anemic Domain models 。
贫血领域模型基本上由轻量级对象组成，它们比任何东西都更像DTO，并且底层服务可以解决繁重的问题。
您在上面描述的架构似乎是混合设计。我猜你现在必须遇到将EF类映射到域对象的问题，这会创建另一层对象，除非你使用POCO，在这种情况下你会遇到命名空间问题而不是。
无论如何，我认为没有行业标准。我可以告诉你的是，我已经看到了一些模式出现在这里和那里倾向于贫血领域模型，并不难看出原因。在断开连接的环境（例如Web，API）中，复杂对象不能很好地工作，因此服务的富裕。
由于您已经很好地分层应用程序并且不希望暴露域模型对象，因此我建议您在服务实现中使用Anemic Models。这些本质上可以作为DTO对象，如果需要可以重用和序列化，但也可以实现甚至可以映射回服务中实现的功能的基本逻辑。
最后说明，没有一个适合所有人的规模。使用正确的工具完成工作。模式应该是指导原则，而不是逐步说明，因此请确保您可以随意调整它们以满足您的特定需求，同时保留一般的想法。
您可以在此处阅读有关贫血领域模型的更多信息： https://en.wikipedia.org/wiki/Anemic_domain_model
请务必查看Martin Fowler对Anemic Domain Models的反对意见： http://www.martinfowler.com/bliki/AnemicDomainModel.html