>数据访问层：用于将数据持久保存到任意数据库的逻辑
>域：数据模型
>服务层：业务逻辑(例如订单处理，帐户管理等)
>控制器：消耗服务并向/向View提供/接收数据
>查看：用户的用户界面
本质上，我使用模型并将其拆分为DAL，服务层和域。我觉得填充模型中的所有逻辑使我的代码过于复杂。此外，我觉得它让我干净利落地表达我的业务逻辑，而不会让控制器做太多工作。
我的问题是：这种类型的架构叫什么？
作为第二个问题：这种类型的架构是否有意义？如果没有，我做错了什么？
解决方法
此外，DDD技术上没有“服务层”。可能存在“应用层”，但它应该很薄，并且只负责应用程序流/管理域类的生命周期。这基本上是Controllers在.NET MVC中所做的事情，在web http的上下文中管理应用程序流。
如果填充模型中的所有逻辑使得代码过于复杂，我会有兴趣听到“过于复杂”的含义示例。您可以正确地为复杂域建模，或者您可能已经使用DDD模式来解决复杂问题。我会说，正如你在问题中列出的那样，拱门不是DDD。我只是称之为“分层架构”，但那是因为我更喜欢在谈论物理拱时使用术语“层”。但是，您的逻辑体系结构是分层的。
我真的很喜欢Darin在他的回答中与Onion arch相关联。我正在成为它的忠实粉丝，我发现它根本不属于DDD。如果您的代码使用依赖注入来解决与运行时实现的接口依赖关系，那么您可能有一种洋葱拱形式。例如，您是否在DAL中定义了任何接口？这些接口的实现是否在运行时解决？
这是我开始在我的新项目中使用的拱的示例。它是洋葱DDD的组合：
> API项目/程序集：所有其他层使用的通用接口，枚举，类和扩展方法。不必与Domain分开，但可以。
>域项目/汇编：所有实体和业务逻辑。仅取决于API。使用DDD模式，如工厂，服务，规范，存储库等。还包含更多特定于域的接口，这些接口未在API中定义。
> Impl Project / Assembly：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项目。
