asp.net-mvc – 这叫什么类型的架构？

你是关于DDD的正确的轨道，取决于领域和领域的薄/厚度。服务层是。 DDD表示应该将知识(即业务逻辑)压缩到域模型中。将数据访问问题转移到DAL与DDD一致，但我认为将业务逻辑移到服务层中则不然。如果您有一个瘦的“数据模型”层(主要用于实体)和一个厚的服务层(主要用于“业务逻辑”)，则可能有一个 anemic domain。

此外，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项目。