企业应用体系结构模式--整合业务数据
为了快速概述我的应用程序体系结构，我在我的应用程序中有以下几个层：
- 域模型-对问题域和业务规则进行建模。
- 服务模型-对应用程序使用的服务契约进行建模。
- 数据访问层-域模型的持久性，在本例中使用EF。
- 服务-服务模型的实现。
- 网站- MVC web应用程序。
- Web - RESTful web服务API。
现在的问题是Web出现得更晚；MVC web应用程序是构建在体系结构之上的第一件事。
我发现自己不得不将业务逻辑和ViewModels (MVC)和Messages (Web )...According复制到枯燥的原则中，我不应该这样做，因此，自然的解决方案是将业务逻辑推入其独立于应用层的层中。
But...this意味着业务逻辑层需要自己的一组模型，这些模型位于应用层和业务逻辑层之间。在这方面，它将不适用于使用域模型，因为这些模型实际上不应该触及应用程序层。
总之，我在寻找一个业界公认的业务逻辑建模标准。对于应该如何工作，是否有公认的标准，如果是，哪种类型的模型(即，它不是域模型，也不是视图模型)属于业务逻辑层？
回答 1
Stack Overflow用户
发布于 2016-11-16 21:26:49
你偶然发现了一个有争议的讨论点。我自己也与此斗争了很长一段时间。
对象偏执狂会争辩说，您甚至不应该有一个服务层。然后可以直接使用域模型，这将消除逻辑的重复。诚然，这是过去软件建模的好时光。随着web、apis和SOA的出现，我们不得不考虑对软件建模的其他方法。输入贫血域模型。
贫血的领域模型本质上是由轻量级的对象组成的，这些对象比任何东西更像DTO，底层的服务可以完成繁重的任务。
上面描述的架构似乎是一种混合设计。我猜想，到目前为止，您肯定遇到了将EF类映射到域对象的问题，这会创建另一层对象，除非您使用POCOs，在这种情况下，您会遇到名称空间问题和其他不存在的问题。
无论如何，我不认为有一个行业标准。我能告诉你们的是，我看到一些模式出现在这里和那里，倾向于贫血的领域模型，不难看出为什么。在断开连接的环境(如web、API)中，复杂对象不能很好地工作，因此服务非常丰富。
由于您已经很好地分层了您的应用程序，并且不希望公开您的域模型对象，我建议在您的服务实现中使用贫血模型。这些基本功能是DTO对象，如果需要，这些对象可以重用和序列化，但也可以实现基本逻辑，甚至可以映射回服务中实现的功能。
最后一点是，没有一刀切的办法。使用合适的工具来完成这项工作。模式应该是指导方针，而不是一步一步的指导，所以确保你可以自由地调整它们，以满足你的特殊需求，同时保留你的总体想法。
您可以在这里阅读更多关于贫血域模型的内容：model
确保检查Martin对贫血领域模型的反对意见：http://www.martinfowler.com/bliki/AnemicDomainModel.html
https://stackoverflow.com/questions/40641983
复制相似问题
腾讯云开发者
