这称为什么类型的架构? [英] What type of architecture is this called?

问题描述

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

For the web application (ASP.NET MVC) I'm currently developing, we have the following architecture in place:

• 数据访问层:将数据持久化到任意数据库的逻辑
• Domain:数据模型
• Service Layer:业务逻辑(例如订单处理、账户管理等)
• Controller:消费服务并向/从视图提供/接收数据
• View:用户的用户界面

• Data Access Layer: Logic for persisting data to an arbitrary db
• Domain: The data model
• Service Layer: Business logic (e.g. order processing, account management, etc.)
• Controller: Consumes services and provides/receives data to/from the View
• View: The user interface for the user

本质上，我把Model分成了DAL、Service Layer和Domain.我觉得把所有的逻辑都塞进 Model 中，让我的代码变得过于复杂.此外，我觉得它可以让我清楚地表达我的业务逻辑，而不会让控制器做太多工作.

In essence, I took the Model and split it up into the DAL, Service Layer and Domain. I felt that stuffing all the logic within the Model made my code overly complicated. Furthermore, I felt that it let me express my business logic cleanly without making the controller do too much work.

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

My question then is: What is this type of architecture called?

作为次要问题:这种类型的架构有意义吗?如果没有，我做错了什么吗?

As a secondary question: Does this type of architecture make sense? If not, am I doing something wrong?

推荐答案

你在 DDD 的正确轨道上取决于域的细/厚服务层是.DDD 说知识(即业务逻辑)应该被压缩到域模型中.将数据访问问题转移到 DAL 符合 DDD，但我认为将业务逻辑移出到服务层则不然.如果你有一个薄的领域数据模型"层(主要用于实体)和一个厚的服务层(主要用于业务逻辑")，你可能有一个 贫血域.

You are on the right track about DDD depending on how thin / thick the domain & service layers are. DDD says that the knowledge (i.e. business logic) should be crunched into the domain model. Moving data access concerns to the DAL is in line with DDD, but I think moving business logic out into a Services Layer is not. If you have a thin Domain "data model" layer (mostly for entities) and a thick Services layer (mostly for "business logic"), you may have an anemic domain.

此外，从技术上讲，DDD 中没有服务层".可能有一个应用层"，但它应该很薄，并且只负责应用程序流/管理域类生命周期.这本质上是控制器在 .NET MVC 中所做的，在 web http 上下文中管理应用程序流.

Also, there is technically no "Service Layer" in DDD. There may be an "Application Layer", but it should be thin, and only be responsible for application flow / managing domain class lifetimes. This is essentially what Controllers do in .NET MVC, manage application flow in the context of web http.

如果在模型中填充所有逻辑会使您的代码过于复杂，我很想听听您所说的过于复杂"是什么意思的示例.您可能正确地建模了一个复杂的域，或者您可能已经使用 DDD 模式来简化事情.我会说，正如您在问题中列出的那样，拱门不是 DDD.我只是将其称为分层架构"，但那是因为我更喜欢仅在谈论物理架构时使用层"一词.但是，您的逻辑架构是分层的.

If stuffing all of the logic within the Model made your code overly complicated, I'd be interested to hear examples of what you mean by "overly complicated". You could be correctly modeling a complex domain, or there are chances you could have gone to DDD patterns to uncomplicate things. I would say as you have listed it in your question, the arch is not DDD. I would just call it "Layered architecture", but that's because I prefer to use the term "tier" only when talking about physical arch. However, your logical architecture is layered.

我真的很喜欢 Darin 在他的回答中与 Onion arch 相关联.我正在成为它的忠实粉丝，而且我发现它根本不是 DDD 独有的.如果你的代码使用依赖注入来解决与运行时实现的接口依赖，那么你可能有一种洋葱结构的形式.例如，您是否在 DAL 中定义了任何接口?这些接口的实现是否在运行时解决?

I really like that Darin linked to Onion arch in his answer. I'm becoming a big fan of it, and I find it's not exclusive to DDD at all. If your code uses dependency injection to solve interface dependencies with runtime implementations, you may have a form of onion arch. For example, do you define any interfaces in your DAL? Are implementations of those interfaces solved at runtime?

这是我开始在新项目中使用的拱门示例.这是洋葱 + DDD 的组合:

Here is an example of an arch I am starting to use in my new projects. It's a combination of onion + DDD:

• API 项目/程序集:所有其他层使用的通用接口、枚举、类和扩展方法.不需要与域分开，但可以.

• API Project/Assembly: generic interfaces, enums, classes, and extension methods used by all other layers. Need not be separate from Domain, but may.

Domain 项目/程序集:所有实体和业务逻辑.仅依赖于 API.使用 DDD 模式，如工厂、服务、规范、存储库等.还包含更多未在 API 中定义的特定领域接口.

Domain Project/Assembly: all entities and business logic. Depends on API only. Uses DDD patterns like factory, service, specification, repository, etc. Also contains more domain-specific interfaces which are not defined in the API.

Impl 项目/程序集:API 和 Domain 中定义的接口的实现.这是实现 EF DbContext 以及日志记录、电子邮件发送等的地方.所有这些实现都是依赖注入的，因此从技术上讲，您可以拥有多个 Impl 项目/程序集.

Impl Project/Assembly: implementations of interfaces defined in API and Domain. This is where the EF DbContext is implemented, as well as things like logging, email sending, etc. All of these implementations are dependency-injected, so technically you could have several Impl projects / assemblies.

UI 项目/程序集:这是 MVC 项目.控制器直接使用域表面，不经过应用程序或服务层.工厂、服务、存储库等中的任何接口依赖项都由控制器使用 MVC IoC(构造函数注入)注入到域中.

UI Project/Assembly: This is the MVC project. Controllers consume the domain surface directly, and do not go through an application or service layer. Any interface dependencies in factories, services, repositories, etc, are injected into the domain by the controller using MVC IoC (constructor injection).

我在最核心放置了一个 API 层，但您可以将 API 和域项目合二为一.无论哪种方式，洋葱的大肉部分是域，它具有内部分层.例如，服务可能依赖于工厂，工厂依赖于存储库，而存储库依赖于实体.

I placed an API layer at the very core but you could combine the API and Domain projects into one. Either way, the big meaty part of the onion is the Domain, and it has internal layering. For example Services may depend on Factories, which depend on Repositories, which depend on Entities.

Impl 项目就是您在巴勒莫的图表中看到的基础设施"洋葱皮.它与 UI 一起位于外边缘，并且不包含特定于领域的知识.它知道如何使用 EF 发送电子邮件、存储/检索数据等.如果您愿意，您可以拥有 1 个以上的这些——例如，1 个用于数据访问的 Impl，1 个用于处理邮件的 Impl，等等.

The Impl project is what you see as the "Infrastructure" onion skin in Palermo's diagram. It is at the outer edge along with the UI, and contains no domain-specific knowledge. It knows how to send email, store/retrieve data using EF, etc. If you want, you can have more than 1 of these -- for example 1 Impl for data access, 1 Impl for dealing with mail, etc.

MVC 具有控制器和视图，并专注于 UI 和 Web 应用程序流.任何需要特定领域知识的东西都被委托给域，域类是注入控制器的构造函数.这意味着域类中的任何构造函数注入接口都由 IoC 容器自动解析.

MVC has the Controllers and Views, and concentrates on the UI and web application flow. Anything that requires domain-specific knowledge is delegated out to the domain, and domain classes are constructor injected into the controller. This means any constructor-injected interfaces in domain classes are resolved automatically by the IoC container.

最后一点，针对 API 和域类中定义的接口进行编程意味着您可以将域项目与 MVC 项目分开进行单元测试.

As a final note, programming against interfaces defined in the API and Domain classes means you can unit test the domain project separately from the MVC project.

这篇关于这称为什么类型的架构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！