为了让您快速了解我的应用程序架构，我的应用程序中包含以下层：
-
Domain Model - 为问题域和业务规则建模 .
-
Service Model - 为应用程序使用的服务 Contract 建模 .
-
Data Access Layer - 域模型的持久性，在本例中使用EF .
-
Services - 服务模型的实现 .
-
Website - MVC Web应用程序 .
-
Web API - RESTful Web服务API .
现在的问题是Web API后来出现了; MVC Web应用程序是第一个构建在体系结构之上的东西 .
我发现自己必须复制业务逻辑和ViewModels（MVC）和消息（Web API）......根据DRY原则，我不应该这样做，所以自然的解决方案是将业务逻辑推入自己的层它独立于应用层 .
但是......这意味着业务逻辑层需要它自己的一组模型，这些模型位于应用层和业务逻辑层之间 . 在这方面，它不适用于使用域模型，因为它们实际上不应该到达应用层 .
简而言之，我正在寻找业界公认的业务逻辑建模标准 . 是否有一个公认的标准应该如何工作，如果是的话，什么类型的模型（即它不是域模型，它不是视图模型）属于业务逻辑层？
1 回答
你偶然发现了一个有争议的讨论点 . 我自己一直在努力解决这个问题很长一段时间 .
对象偏执者会争辩说你甚至不应该有一个服务层 . 然后可以直接使用您的域模型，这将消除逻辑重复 . 当然，那些是软件建模的美好时光 . 随着Web，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