DDD - 域模型，服务和存储库之间的依赖关系 [英] DDD - Dependecies between domain model, services and repositories

问题描述

只想知道别人如何分层他们的架构。说我有我的图层如下：

域图层

- 产品

--ProductService（应该是imp进入此层？）

--IProductService

--IProductRepository

基础设施层

--ProductRepository（在我的域中的IProductRepository的Imp）

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

由于该服务对存储库有依赖关系，因此我将使用IProductRepository接口来设置ProductService ctor，后者可以被注入。如下所示：

  public class ProductService：IProductService 
 {
 private IProductRepository _repository; 
 
 public ProductService（IProductRepository存储库）
 {
 _repository = repository; 
} 
 
 public long GetNextProductId（）
 {
 return _repository.GetNextProductId（）; 
} 
} 
  

我的问题是，当我在产品类在实例化一个新的ProductService类时，我引用了ctor中的Repository。在DDD这个大的没有没有这样的参考。我甚至不确定我的产品域类正在正确设置来调用服务，有人可以提示：

  public class Product：Entity 
 {
 private ProductService _svc; 
私人IProductRepository _repository; 
 
 public产品（字符串名称，地址地址）//在ctor中放置IProductRepository的parm似乎不合适？ 
：base（_svc.GetNextProductId）//这是我传递id 
 {
 //在哪里创建IProductRepository的实例？ 
} 
} 
  

我如何优雅地解决这个设计问题？我有经验的DDD'ers的建议开放

编辑：

感谢您的意见。我也怀疑是否应该从产品类调用该服务。我还没有使用工厂模式（还），因为对象的构造仍然很简单。我不觉得它有工厂方法吗？

我很困惑...把ProductId放在一边，如果我的产品类需要一个服务的其他数据，例如GetSystemDateTime（ ）（我知道，不好的例子，但试图演示一个非db调用）这个服务方法在哪里调用？

DDD中的服务是逻辑转储，逻辑不属于域对象，对吗？那么它如何粘在一起？

解决方案

最后一点，DDD中的服务是将我所描述的尴尬的逻辑。如果您有某种类型的逻辑或工作流依赖于其他实体，则这种逻辑类型通常不适合域对象本身。示例：如果我的业务对象上有一个方法来执行某种类型的验证，那么服务类可能会执行此方法（仍然保持与实体在其类内相关的实际验证逻辑）

另一个很好的例子，我一直提到的是资金转账的方法。您不会有从一个对象转移到另一个对象的帐户对象，而是您将拥有一个服务，其中包含到帐户和从帐户。然后在服务内部，您可以使用从帐户和您的到帐户的存款方式调用提款方式。如果您尝试将其放在帐户实体本身，那将会感到尴尬。

可以找到一个关于这个主题的深入的播客，可以找到rel =noreferrer> http://deepfriedbytes.com/podcast/episode-6-talking-domain-driven-design-with-david-laribee-part-1/ David Laribee做了一个非常好的工作，现在只解释DDD的如何，但是为什么。

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

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

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

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

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();
        }
    }

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?
        }
    }

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

EDIT:

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?

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?

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

解决方案

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)

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.

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 - 域模型，服务和存储库之间的依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！