这叫什么类型的架构？

Question

对于我目前正在开发的Web应用程序(ASP.NET MVC),我们有以下架构:

• Data Access Layer:用于将数据持久保存到任意数据库的逻辑
• Domain:数据模型
• Service Layer:业务逻辑(例如订单处理,账户管理等)
• Controller:使用服务并向View提供/接收数据
• View:用户的用户界面

从本质上讲,我把Model它分成了DAL,Service Layer然后把它分成了Domain.我觉得填充所有逻辑Model使得我的代码过于复杂.此外,我觉得它让我干净利落地表达我的业务逻辑,而不会让控制器做太多工作.

我的问题是:这种类型的架构叫做什么？

作为第二个问题:这种类型的架构是否有意义？如果没有,我做错了什么？

Answer 1

根据域和服务层的薄/厚度,您可以正确地了解DDD.DDD表示应该将知识(即业务逻辑)压缩到域模型中.将数据访问问题转移到DAL与DDD一致,但我认为将业务逻辑移到服务层中则不然.如果您有一个瘦的"数据模型"层(主要用于实体)和一个厚的服务层(主要用于"业务逻辑"),您可能会有一个贫血的域.

此外,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项目.

Answer 2

从高层次来看,我将其描述为分层架构.将其描述为域驱动设计也会考虑较小的模式,如聚合,存储库,有界上下文等.我无法从您的描述中分辨出来.

如果域层驻留在不引用任何其他域的程序集/包中,那么它具有Onion Architecture原则的核心,它们是:

• 该应用程序围绕独立的对象模型构建
• 内层定义接口.外层实现接口
• 耦合方向朝向中心
• 所有应用程序核心代码都可以编译并与基础架构分开运行

要查找的具体内容是您的DataAccess是否引用了Domain.

Answer 3

根据您所看到的角度,可能会有不同的名称.所以它仍然是MVC,只是你的M被分成多层.它也可以称为Multitier架构(或N层架构).Jeffrey Palermo也使用了洋葱建筑的概念.