How to structure a cart with cart products object

Question

I am new to DDD and I am having trouble structuring an object. I have a cart, where I can add products to it. Each product has some properties like image, title, price, etc. Whenever a product is added to the cart, the database stores this relation in a separate table, called cart_products. This new table allows me to add some new properties to the cart product, like an observation, it has an id different from that of the product in the products table, it can have additionals like "fries for a cheeseburguer", so on. So, if I am working on a cart object, which has products (which come from the cart_products table), should I have a cart.products, which would be an array of products, where each product will be a cart_product, with an id, observation and then a property product which has all the properties of product, like image, title, price, or I can have all these properties directly inside my product? Basically.

cart = {
  products = [                        // this product comes from `cart_products` table
   id = 1
   observation = 'text text text'
   product = {                        // this product comes from `products` table
    image: 'url'
    name: 'Cheese'
    price: 2.0
   }
  ]
}

or

cart = {
  products = [
    {                       // this product comes from `cart_products` table
      id = 1
      observation = 'text text text'
      image: 'url'                       // this property comes from `products` table
      name: 'Cheese'                     // this property comes from `products` table
      price: 2.0                         // this property comes from `products` table
    }
  ]
}

Using the idea of Ubiquitous Language, it seems like the second fits better, but I don't know it that's correct (or, at least, makes more sense)

Answer 1

There are multiple ways to structure this, which are independent of Domain Driven Design. The Ubiquitous Language mentioned in DDD guides you in naming things. Within the realm of e-commerce, products, cart and prices are all concepts in that domain. Nothing stands out as incorrect from an outsider's perspective, but my perspective is not the one that counts. Your organization and customer will drive the ubiquitous language.

DDD does not provide guidance on the data structure. For that, consider which part of the application architecture you are operating in. One of your comments mentions this is data used in a View component, which is likely pulled in from a REST API call. The needs of the user interface and the abstraction provided by the REST endpoint are more relevant here.

The choice to decompose the product information from the shopping cart item information is up to you. It should be a balance between ease of implementation on the backend and frontend. If your view has a component to render product details, it might make sense to have a separate object for the product and shopping cart information. If there is no need to reuse view components at this level, the KISS principal can apply: put all of the necessary properties in a single object.

Answer 2

Actually, you get to choose. Whatever makes the most sense to you.

This is one of the beauties of properly separated code. You are able to define what your persistence CartProduct (i.e. the table entity) looks like, completely unrelated to what the domain CartProduct looks like. You don't need to consider one when considering the other.

It is perfectly possibly for your domain CartProduct to choose to not explicitly reveal the underlying Product, instead opting to pretend like these are its own properties. This is possible because there is nothing that tells you that your domain model structure somehow "must" stay true to the table structure. Doing so would be a form of tight coupling, which is what you don't want.

Loose coupling gives you the freedom of choice here whether you choose to replicate the same structure in your domain or to create a different structure that better suits your needs in the domain logic.