4

I understand that there exists duplicity of data between Bounded Contexts. The thing is that I'm not really sure about duplicity of data between Aggregate roots.

Example: I have product in Product aggregate and also Product in Cart aggregate. Both are in same BC (ShoppingCart) and share few fields (name, description, ...). MySQL is used as storage. Should product in both aggregates be stored in one table or separately?

I don't mind duplicity, but in this case there would be n products in database for n cart items.

Diagram

  • 1
    In the example, you say both are in the same Bounded Context, yet the question then refers to "both contexts" (what two contexts?). This is confusing the question, at least in my mind. Can you clarify? – Erik Eidt Jun 16 '15 at 15:06
  • I meant aggregate. I updated the question. Now it should make more sense. :) – František Maša Jun 16 '15 at 15:10
  • A shopping cart doesn't have a list of products. It has a list of purchased items. A purchased item is a (ProductId + Quantity). The purchased item would have a reference to the ProductId of the Product entity in the Listing BC. – Songo Jun 16 '15 at 22:24
  • @Songo I also have Product in Catalogue (Listing) context. My implementation is slightly different (I actually use Cart->CartItem->ProductVO in cart) But in Cart I care only about specific things related to Product (gifts, that user can select in cart, additional services, that user can select and so). – František Maša Jun 16 '15 at 22:37
  • 1
    @FrantišekMaša I'm not sure that I follow what your are trying to achieve, but if you need your cart item to have the product name then instead of (ProductId + Quantity) make it a (ProductValueObject + Quantity). The ProductValueObject will consists of (ProductId + ProductName) – Songo Jun 17 '15 at 22:44
3

I think you want to go for a design of normalization within one Bounded Context. If one aggregate is a pure subset of the other (e.g. the product for cart is a subset of the product for product) I'd probably use a single table. Otherwise, I'd probably use a second table that refers to the first table rather than duplicating columns between two tables.

For what it's worth, I'm not convinced that the two different product items you're describing are both aggregates. One or both may be merely entities or value objects; perhaps there really is only one product aggregate in this BC.


Update

Based on your diagram: in the cart domain, you want a collection of references to products (by Product ID). I wouldn't even call that collection a product table, but instead I'd call that a cart item table. This cart item table would have fields relevant to cart items, such as: the cart table item id, a product table foreign key reference, maybe along with things applicable to cart'ing but not products, like say, a count of the number of this product item being ordered, and even timestamp of when added to the cart (price at the time added to the cart, etc...).

I wouldn't duplicate any product table columns in the cart item table. When you need a product item column value (such as description), you use a join from the cart item table to get it.

(If/when you find that for performance reasons you want to start making these more independent, then it is worth starting to think of these as different bounded contexts, because decoupling these things for performance introduces new (consistency management) responsibilities. In between two different contexts, you can use translation, duplication & caching, and eventing, as necessary when you might run multiple databases for performance.)

  • They aren't aggregate in both cases. – František Maša Jun 16 '15 at 15:27
  • I'll post a diagram from home. – František Maša Jun 16 '15 at 15:28
  • finally added diagram. Aggregates aren't complete, I'm just pointing out that Product is once "normal" entity and once AR. – František Maša Jun 16 '15 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.