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

Question

只是想知道其他人如何将其体系结构分层。说我的图层如下：

域层
- 产品
--ProductService（imp应该进入这一层吗？）
--IProductService
--IProductRepository

基础设施层
--ProductRepository（我域中IProductRepository的Imp）

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

因为该服务对存储库有依赖性，所以我使用IProductRepository的接口设置了ProductService ctor，以后可以将其注入。像这样的东西：

    public class ProductService : IProductService
    {
        private IProductRepository _repository;

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

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

我的问题是，当我在产品类中使用服务时，在实例化新的ProductService类时正在引用ctor中的存储库。在DDD中，有这么一个参考是很大的不。我什至不确定我的产品域类是否已正确设置以调用服务，有人可以建议：

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'ers的建议

编辑：

感谢您的评论。我也怀疑是否应该从产品类中调用该服务。我还没有使用工厂模式，因为对象的构造仍然很简单。我不认为可以采用工厂方法吗？

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

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

Answer 1

到最后一点，DDD中的服务是放置我所描述的“笨拙”逻辑的地方。如果您有某种逻辑或工作流程依赖于其他实体，则这是通常不“适合”域对象本身的逻辑类型。示例：如果我在业务对象上有一个方法可以执行某种类型的验证，则服务类可以执行此方法（仍将与实体相关的实际验证逻辑保留在其类内）

我经常提到的另一个非常好的例子是资金转帐方法。您不会将帐户对象从一个对象转移到另一个对象，但是您将拥有使用“ to”帐户和“ from”帐户的服务。然后在服务内部，您将调用“发件人”帐户上的提款方法，以及“收款人”帐户上的存款方法。如果您尝试将其放入帐户实体本身，则会感到尴尬。

可以找到一个很好的播客，深入讨论这个话题。大卫·拉里比（David Laribee）做得非常出色，现在只解释了DDD的“方法”，但解释了“为什么”。