DDD和域接口/类 [英] DDD and domain interfaces/classes

问题描述

在我的应用程序中，我有一个程序集-MyApplication.Core，其中包含我所有的域对象-客户，订单等，以及存储库的接口-ICustomerRepository，IOrderRepository

In my application I have an assembly - MyApplication.Core which contains all of my domain objects - Customer, Order etc, as well as interfaces for repositories - ICustomerRepository, IOrderRepository

我有另一个程序集-MyApplication.Data，其中包含这些接口的具体实现-OrderRepository等.这些存储库负责从数据库中检索数据并使用域对象将其呈现.

I have another assembly - MyApplication.Data which contains concrete implementations of those interfaces - OrderRepository etc. The repositories are responsible for retrieving data from the DB and presenting it using the domain objects.

我不确定的一件事是我的域对象应该是类还是接口.对我来说，在我的Core程序集中定义诸如ICustomer，IOrder之类的接口是否有意义，然后让Data程序集提供具体的实现?从我到目前为止所读的内容来看，似乎推荐使用实际的类，这背后的原因是什么?

One thing I'm not sure about is whether my domain objects should be classes or interfaces. Would it make more sense for me to define interfaces like ICustomer, IOrder in my Core assembly, and then have the Data assembly provide the concrete implementations? From what I've read so far, it seems that actual classes are recommended, what is the reason behind this?

推荐答案

不需要将您的集合，实体和值对象定义为接口，因为您不应该避免将其他代码耦合到它们. 洋葱体系结构中的每一层都可以直接依赖于您的核心/型号.另一个好的经验法则是，很难想象例如Customer的替代实现.

Your Aggregates, Entities and Value objects don't need to be defined as interfaces because you should not be trying to avoiding coupling other code to them. Every layer in the Onion Architecture is allowed to have a direct dependency on your Core/Model. Another good rule of thumb is that it is hard to imagine an alternative implementation of the Customer for example.

另一方面，通常将存储库定义为接口，以便使用它们的代码不会依赖于用于实现存储库的ORM(或数据访问库).

Repositories on the other hand are usually defined as interfaces so that the code that uses them does not get a dependency on ORM (or data access libraries) that you use to implement a repository.

谈到DDD上下文之外的接口，我发现Mark Seemann的这篇文章非常有用:接口不是抽象.

Speaking of interfaces outside DDD context, I find this article by Mark Seemann very useful: Interfaces are not abstractions.

对我来说，定义ICustomer之类的接口是否更有意义， 在我的Core程序集中添加IOrder，然后让Data程序提供 具体的实现方式?

Would it make more sense for me to define interfaces like ICustomer, IOrder in my Core assembly, and then have the Data assembly provide the concrete implementations?

这可能表明您的域对象实际上是数据对象，并且该设计受 AnemicDomainModel的影响反模式.为什么数据汇编会包含业务逻辑的实现?

This may be a sign that your domain objects are really data objects and the design suffers from the AnemicDomainModel anti-pattern. Why would Data assembly contain implementation of the business logic?

这篇关于DDD和域接口/类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！