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?

  • 3
    Again a question supposedly about DDD, but in reality it’s about data.
    – Rik D
    Jul 21, 2023 at 12:27
  • 2
    Agreed with @RikD. The problem here is not domain-driven design. DDD does not make a recommendation here. Your decision to duplicate data or store Ids is a technical decision, not a business decision. Can you edit your question to include more of the architectural details? Remember that DDD is a design philosophy, not an architecture. Your application architecture and performance requirements will likely determine the correct answer. Jul 21, 2023 at 13:02

2 Answers 2


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.


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).

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Jul 25, 2023 at 3:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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