对于我目前正在开发的Web应用程序（ASP.NET MVC），我们有以下架构：
Data Access Layer：将数据保存到任意数据库的逻辑Domain：数据模型Service Layer：业务逻辑（例如订单处理，帐户管理等）Controller：使用服务并向View提供/接收数据View：用户的用户界面从本质上讲，我拿了Model并将其拆分为DAL，Service Layer和Domain。我觉得填充Model中的所有逻辑使我的代码过于复杂。此外，我觉得它让我能够干净地表达我的业务逻辑而不会让控制器做太多工作。
我的问题是：这种类型的架构叫做什么？
作为次要问题：这种类型的架构是否有意义？如果没有，我做错了吗？
答案 0 :(得分：25)
您在DDD的正确轨道上，取决于域和/的厚度/厚度。服务层是。 DDD表示应该将知识（即业务逻辑）压缩到域模型中。将数据访问问题转移到DAL与DDD一致，但我认为将业务逻辑移到服务层中则不然。如果您有一个瘦的“数据模型”层（主要用于实体）和一个厚的服务层（主要用于“业务逻辑”），那么您可能有一个anemic domain。
此外，DDD技术上没有“服务层”。可能存在“应用层”，但它应该很薄，并且只负责应用程序流/管理域类的生命周期。这基本上是Controllers在.NET MVC中所做的事情，在web http的上下文中管理应用程序流。
如果填充模型中的所有逻辑使得代码过于复杂，我会有兴趣听到“过于复杂”的含义示例。您可以正确地为复杂域建模，或者您可能已经使用DDD模式来解决复杂问题。我会说，如你在问题中列出的那样，拱门不是DDD。我只是称之为“分层架构”，但那是因为我更喜欢在谈论物理拱时才使用术语“层”。但是，您的逻辑体系结构是分层的。
我真的很喜欢Darin在他的回答中与Onion arch相关联。我正在成为它的忠实粉丝，我发现它根本不属于DDD。如果您的代码使用依赖注入来解决与运行时实现的接口依赖关系，那么您可能有一种洋葱拱形式。例如，您是否在DAL中定义了任何接口？这些接口的实现是否在运行时解决？
以下是我在新项目中开始使用的拱门示例。它是洋葱+ DDD的组合：
API项目/汇编：所有其他层使用的通用接口，枚举，类和扩展方法。不必与Domain分开，但可以。
Domain项目/大会：所有实体和业务逻辑。仅取决于API。使用DDD模式，如工厂，服务，规范，存储库等。还包含更多特定于域的接口，这些接口未在API中定义。
Impl项目/大会：API和Domain中定义的接口的实现。这是实现EF DbContext的地方，以及日志记录，电子邮件发送等等。所有这些实现都是依赖注入的，所以从技术上讲，你可以有几个Impl项目/程序集。
UI项目/大会：这是MVC项目。控制器直接使用域表面，而不是通过应用程序或服务层。工厂，服务，存储库等中的任何接口依赖关系都由控制器使用MVC IoC（构造函数注入）注入域中。
我在最核心放置了一个API层，但您可以将API和Domain项目合并为一个。无论哪种方式，洋葱的大肉部分是域，它有内部分层。例如，服务可能依赖于工厂，工厂依赖于依赖于实体的存储库。
Impl项目就是您在巴勒莫图中看到的“基础设施”洋葱皮。它与UI一起位于外边缘，并且不包含特定于域的知识。它知道如何使用EF发送电子邮件，存储/检索数据等。如果需要，您可以拥有多于1个 - 例如1个Impl用于数据访问，1个Impl用于处理邮件等。
MVC具有控制器和视图，并专注于UI和Web应用程序流。任何需要特定于域的知识的东西都被委托给域，而域类是构造函数注入到控制器中。这意味着域类中任何注入构造函数的接口都由IoC容器自动解析。
最后需要注意的是，针对API和Domain类中定义的接口进行编程意味着您可以单独测试域项目与MVC项目。
答案 1 :(得分：21)
从高层次来看，我将其描述为分层架构。将其描述为域驱动设计也会考虑较小的模式，如聚合，存储库，有界上下文等。我无法从您的描述中看出。
如果域层位于不引用任何其他域的程序集/包中，则它具有Onion Architecture principles的核心，它们是：
要查找的具体内容是您的DataAccess是否引用了域。
答案 2 :(得分：5)
根据您所看到的角度，可能会有不同的名称。所以它仍然是MVC，只是你的M被分成多层。它也可以称为Multitier architecture（或N层架构）。 Jeffrey Palermo也使用了Onion architecture的概念。
答案 3 :(得分：4)
由于您已将DAL与域模型分开并且还具有服务层，因此看起来您正在前往DDD（域驱动设计），这里讨论的是an approach，这可能对您有用。