DDD - 域模型、服务和存储库之间的依赖关系

问题描述

只是想知道其他人是如何对他们的架构进行分层的.假设我的图层如下:

Just wanted to know how others have layered their architecture. Say I have my layers as follows:

领域层
--产品
--ProductService(小鬼是否应该进入这一层?)
--IProductService
--IProductRepository

Domain Layer
--Product
--ProductService (Should the imp go into this layer?)
--IProductService
--IProductRepository

基础设施层
--ProductRepository(我域中 IProductRepository 的导入)

Infrastructure Layer
--ProductRepository (Imp of IProductRepository in my domain)

现在，当创建新产品时，我需要通过调用 ProductService.GetNextProductId() 方法来分配产品 ID.

Now when a new product is created i have a requirement to assign a product id by calling into the ProductService.GetNextProductId() method.

因为该服务依赖于存储库，所以我使用 IProductRepository 接口设置了 ProductService ctor，该接口可以在以后注入.像这样:

Because the service has a dependency on the repository i set up the ProductService ctor with an interface of IProductRepository which can be injected later. something like this:

    public class ProductService : IProductService
    {
        private IProductRepository _repository;

        public ProductService(IProductRepository repository)
        {
            _repository = repository;
        }

        public long GetNextProductId()
        {
            return _repository.GetNextProductId();
        }
    }

我的问题是，当我在产品类中使用服务时，我在实例化新的 ProductService 类时引用了构造函数中的存储库.在 DDD 中，有这样一个参考是一个很大的禁忌.我什至不确定我的产品域类是否设置正确以调用该服务，请有人建议:

My issue is that when i use the service in the Product Class i am making reference to the Repository in the ctor when instantiating a new ProductService class. In DDD its a big no no to have such a reference. I' am not even sure if my product domain class is being set up correctly to call the service, can someone pls advise:

public class Product : Entity
    {
        private ProductService _svc;
        private IProductRepository _repository;

        public Product(string name, Address address) //It doesnt seem right to put parm for IProductRepository in the ctor?
            : base(_svc.GetNextProductId) // This is where i pass the id
        {
            // where to create an instance of IProductRepository?
        }
    }

我怎样才能优雅地解决这个设计问题?我愿意听取有经验的 DDD 人员的建议

How can i elegantly solve this design issue? I am open to suggestions from experienced DDD'ers

感谢您的评论.我也怀疑是否应该从产品类调用该服务.我还没有使用工厂模式(还)，因为对象的构造仍然很简单.我不觉得它需要工厂方法吗?

Thanks for you comments. I also doubted if the service should be called from the Product Class. I have not used a factory pattern (yet) as the construction of the object is still simple. I dont feel it warrants a factory method yet?

我很困惑......如果我的产品类需要来自服务的一些其他数据，例如 GetSystemDateTime()(我知道，不好的例子，但试图演示非数据库调用)将 ProductId 放在一边，这个服务方法在哪里叫?

I' am confused...Putting the ProductId aside if my Product class needed some other data from a Service e.g GetSystemDateTime() (i know, bad example but trying to demonstrate a non db call) where would this service method be called?

DDD 中的服务是逻辑转储，其中逻辑对域对象来说不是自然的，对吗?那么它是如何粘合在一起的?

Services in DDD are logic dumps where the logic is not natrual to the domain object, right? So How does it glue together?

推荐答案

最后一点，DDD 中的服务是放置我所说的尴尬"逻辑的地方.如果您有某种类型的逻辑或工作流依赖于其他实体，那么这种逻辑类型通常不适合"域对象本身.示例:如果我的业务对象上有一个方法来执行某种类型的验证，则服务类可能会执行此方法(仍将与实体相关的实际验证逻辑保留在其类中)

To your last point, services in DDD are a place to put what I describe as "awkward" logic. If you have some type of logic or work flow that has dependencies on other entities this is the type of logic that usually doesn't "fit" inside a domain object itself. Example: If I have a method on my business object to perform some type of validation, the service class might execute this method (still keeping the actual validation logic related to the entity inside its class)

我经常提到的另一个非常好的例子是资金转移方法.您不会将帐户对象从一个对象转移到另一个对象，而是拥有一个接受to"帐户和from"帐户的服务.然后在服务内部，您将调用from"帐户上的提款方法和to"帐户上的存款方法.如果您试图将其放入帐户实体本身，那会感觉很尴尬.

Another really good example I always mention is the funds transfer method. You wouldn't have an account object transfer from one object to another, but instead you would have a service that takes the "to" account and the "from" account. Then inside the service you would invoke the withdrawal method on your "from" account and the deposit method on your "to" account. If you tried to put this inside the account entity itself it would feel awkward.

可以找到深入讨论这个主题的很棒的播客 此处.David Laribee 做得非常好，现在只解释了 DDD 的方式"，但解释了为什么".

A great podcast that talks in depth about this very topic can be found here. David Laribee does a really good job explaining now only the "how" but the "why" of DDD.

这篇关于DDD - 域模型、服务和存储库之间的依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！