How to use DDD approach to catalog implementation?

Question

Problem-Based Design

Hey!
On a small pet project, I'm learning the tricks of DDD. So, there is a certain analogue of a store: a catalog, a product page, a basket, etc. Reflecting, I came to the conclusion that the concept of "Goods" in the system clearly has at least two meanings. In the context of a catalog, this is more of a representative model - title, description, pictures, etc. In the context of the purchase, these are already prices, all sorts of loyalty programs, discounts, and so on. By and large, the first context is generally more like a regular blog with a set of pages. Therefore, I decided to single out two independent contexts (Bounded Context):
1. Catalog
2. Shop
In both contexts there is the concept of Product, implemented by the class of the same name

namespace Acme\Catalog;

class Product {
  private $id; // Это идентификатор продукта в контексте каталога
  private $name;
  private $description;
  private $poster;
  // ...
}

namespace Acme\Shop;

class Product {
  private $id; // Это идентификатор продукта в контексте продаж
  private $sku;
  private $price;
  // ...
}

The Shop context relies on the Catalog, so the $id key in the product in the Shop context is a surrogate and can always be obtained based on the $id from the Catalog context. Something like:

namespace Acme\Shop

class ShopService {
  public function fromCatalogProduct($id) {
    // тут строим идентификатор на основе каталожного
  }
}

In principle, this approach works quite well when you need to show one product card.

class ProductPageController
{
  // ...
  public function pageAction($id) {
    $catalogProduct = $catalogRepo->get($id);
    $shopId = $shopService->fromCatalogProduct($id);
    $shopProduct = $shopRepo->get($shopId);
    // Дальше рендерим страницу, опираясь на оба контекста
  }
}

Of course, an extra request is not so hot. And with a larger number of contexts involved for display, the number of requests will grow. But for now, for example, tolerable.
And here's what to do when you need to display a catalog page with a lot of products. In theory, I also need both contexts. Solutions seem to be:

1. In the forehead - first, from the Catalog context, we request products, and then for each of them, from the Shop context, we pull the price. The cons are obvious.
   
2. Better - first, we request products from the Catalog context, and then we pull the prices in batches from the Shop context. It still doesn't look good anyway.
   
3. Separate reading model for the directory. After creating or editing products in both contexts, the data is merged into some kind of MongoDB database, from which a ready-made aggregate is taken. Here CQRS to help, even without Event Sourcing, it seems. The only question is creating a reading model and keeping it afloat.
   

Do respected community members have any thoughts on this?

Answer 1

The DDD domain model is purely for organizing business logic, and concepts such as Aggregate, Entity, Value Object serve exclusively these purposes.
To display data in a graphical interface, you can, or even need to, create a second model for reading.
Those. the result should be two models, in many ways they will duplicate themselves in simple areas.

Answer 2

The context must be one.
The essence of the goods must be one.
In your case, Shop\Product - this will be a commodity item, but it must be associated with Catalog\Product so as not to duplicate entities. You just need to use an aggregate that is either from Product or from some other entity (that is, a service related to the entity), such as ProdcutCatalog, PriceList, Reporter, or something else like that.
For example, the service will have the PriceList.GetPriceList(from, to) method, and it already makes the necessary aggregate with queries, but when building the aggregate, the method will access tables related to the Product entity