DDD - Entity model duplication vs Referencing the Entity Id in different bounded contexts

Question

Asume these two bounded contexts:

• Book Management: manages the creation of books and its attributes:

  Book(id, name, author, summary, ISBN, length, cover photo)

• Book Order: creates orders related to books.

  Order(orderId, List<Book>, deliveryDate, status, etc.)

The Book Order context has an independent web application that allows each buyer to order books and check their status.

This application needs to show a subset of the Book info (name, ISBN, cover photo).

There are two options here:

• The book order context stores only a reference to the book ids.

  Order(1, [bookId1, bookId2, ...], 2023-12-12, PENDING,...)

  Order(2, [bookId5, bookId1, ...], 2023-10-12, PENDING,...)

  Whenever it needs to display an order it will have to ask the book management context for the details of each of the books that the order contains, for instance using an Open Host Service.

• The book order context could store a subset of the book entity in its own model.

  Order(1, [Book(bookId1, "The Book", "ISBN1, "http://image.png), ...], 2023-12-12, PENDING,...)

  The book info could be created/updated based on events published from the Book Management context (BookCreated, BookUpdated,...). This prevents it from making an HTTP call per book. However, a downside is that we're duplicating some information from the book entity in different contexts.

Assuming each order could contain between 9 and 20 books, and buyers place at least an order per week, what would be the more sensible approach?

Answer 1

Assuming each order could contain between 9 and 20 books, and buyers place at least an order per week, what would be the more sensible approach?

What I would expect: the book information is reference data; we keep a cached copy of it somewhere convenient (ex: as a reference table within the orders database) and a process that updates the cached reference data on a cadence that satisfies your service level objectives.

Note: this assumes that you've been diligent in your analysis, and that your decision to separate Books from Book Ordering is correct.

Helland 2005 is probably the right starting point; the distinction he introduces between "inside data" and "outside data" is an important one.

Caching isn't free, of course - you'll need to think about cache invalidation, and you might also need to consider edge cases like "what happens if the books reference elides a book that the ordering system cares about?"

Given that your motivation is an application, you might also want to review some of Udi Dahan's ideas about UI composition.

Answer 2

I'm not entirely sure I agree with all of the previous answer - once an order is done, it's a whole thing, and the details within the order become part of the order, so they cease being part of the 'Books' context and move into the 'Order' context. If last year I order 'Dummies Guide to Twitter', but yesterday someone updates the title for the same bookID to 'Dummies Guide to X', my history shouldn't be rewritten (unless of course my order hasn't shipped...). So it's like Greg said in the comment - it's a business-driven decision, not a technical one.

That said, I'd probably be pragmatic about things - I might embed a URL to a cover page in the book-in-an-order record, but I wouldn't copy the cover page graphic file from the Book context.

I'm also not convinced by the UI Composition link above either - I can sort of see the idea, but that was from 2012 or so, and I think the industry has moved on from that sort of logic happening directly in the browser, to a front-end-for-backend pattern.

(In a real application as described above, I'd probably implement a fetch-books-by-list-of-ids call to prevent chattiness too).