Identifier versus link in DDD

I have two cases where I can use an object id or pass it as a reference.

1) Domain services. Example:

class ProductService {
     public void changePrice(Product product, long newPrice) {
          // significant calculations involving several Entities here...
     }
     // versus
     public void changePrice(long productId, long newPrice) {
          Product product = productRepository.get(productId);
          // significant calculations involving several Entities here...
     }
}

      

2) Essence. Example:

class Order {
    public void addItem(Product product, long quantity) {
        // do stuff
    }
    // versus
    public void addItem(long productId, long quantity) {
        Product product = Registry.productRepository().get(productId);
        // do stuff
    }
    // or even maybe this ugly version?
    public void addItem(ProductRepository productRepository, long productId, long quantity) {
        Product product = productRepository.get(productId);
        // do stuff
    }
}

      

Which approach is better and why?

+3


source to share


1 answer


I love Theion Architecture about how to conceptually think about how to protect your domain from outside influences.

IMO, it is better to keep repositories outside the domain. Let layers outside the domain resolve domain entities and then within the domain use them.



So, I would most likely prefer examples directly using Product

(Reference). The storage implementation is not domain-specific. The domain should not be cluttered with IDs, configuration, or persistence. Instead, he should focus on the domain issue directly and with as much clarity as possible.

+1


source







All Articles