The behavior of my systems, is as follows

  1. user places an order for a product
    1a. order management creates a placeholder record for the order
    1b. forwards the order to an external vendor.
  2. external vendor fills the order and also say ships it for delivery
    2a. then returns my system back a list of filled orders only end of day with the tracking ids for shipments
  3. my system needs to update the placeholder record with the filled order details and the user details*

Another important aspect is that we are bulk ordering stock from external vendor. In consequence it can happen that an order placed was cancelled by user A during the day but purchased by user B So there is a mechanism in place to findlastUser() for this order in place.

Say the business now has a hard requirement to keep a central bounded context, named FilledOrderHistory which will be a single Source Of Truth (SOT) for fetching order related data, and separate Bounded Contexts for Orders & Shipments.

So for data flow, I am considering these 2 options:

Option A: enrich and write

  1. external Vendor data --writes--> BC FilledOrderHistory (SEQID, external_order_id)

  2. Enrichment of data A) BC FilledOrderHistory (SEQID, external_order_id) --read--> Unique Identifier for Order from BC Orders & map it to BC FilledOrderHistory using some translation rules B) BC FilledOrderHistory (SEQID, external_order_id) --read--> Unique Identifier for User from BC Users & map it to BC FilledOrderHistory

  3. BC FilledOrderHistory (SEQID, external_order_id) writes a record in a datastore for (SEQID, external_order_id,internal_orderId,internal_userId)

Option B: read and enrich

  1. external Vendor data --writes--> BC FilledOrderHistory (SEQID, external_order_id)

At the time of read, fetch all projections from each BC . other BC will maintain the mapping & translations.

return a record for (SEQID, external_order_id,internal_orderId,internal_userId) `

Challenge: possibility that there could be a new BC in future, say Shipment Tracking for tracing each order with tracking id details as provided in vendor data, and say handle any complaints relating to it.

Question: How do I model the bounded contexts communication? I know that I need to introduce the ACL's but what's the pattern which allow me most flexibility.

  • 1
    ’business now has a hard requirement to keep a central bounded context, named FilledOrderHistory’. A BC enables us to create separate models for the same concept in different parts of our system. Reading your question that’s not what you need. It’s also not something the business should worry about; a BC can be a namespace in code, for example. What is the actual requirement the business gave you?
    – Rik D
    Feb 18 at 7:21
  • ’ How do i model the bounded contexts communication?’ It’s not clear to me what you want to know. Do you mean if the API from BC A should use concepts from A on the public interface or create a specific ACL API that translates the concepts to be in line with what the downstream BC B expects?
    – Rik D
    Feb 18 at 7:28
  • thanks for reply. my issue is with the modelling FilledOrderHistory as a concept.. since this FilledOrderHistory concept would always be referenced from another Bounded Context, like List<FilledOrderHistory> getOrderHistoryForUser(UserId id) .. i could have split the data when it arrived and put it in a BC where it was more appropriate.. now i think having a central BC would require a cyclic dependency between BC FOH to fetch the internalId from BC orders at time of write.. and BC Orders will always have to query BC FOH for detailed history information ..
    – Sneha
    Feb 18 at 12:26

1 Answer 1



First of all, I'm just starting to dip my toe in DDD so take my suggestions cautiously.

You are already filling your Order with the details from the vendor's response. What's the difference between those details and FilledOrderHistory?

If you can retrieve the vendor's response using and ID maybe all you need is to raise an event like PurchaseIntendProcessed(vendorID).

In the Order's BC you just need to process that event. And if another BC like Shipment is created, all you need to do is create another handler on that BC.

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.