Two event based bounded contexts, how to load initial data?

0
votes

How would I load initial data (from the UI let's say) when integrating two Bounded Contexts via messaging?

Example:

  1. Bounded Context #1 - Airport
  2. Bounded Context #2 - User Agent (UI) - Responsible for displaying/updating Airplaines in the airport.

When UI is just starting, I want to query the "Airport" for ALL airplaines. How would I go about it?

My current thinking is to simulate a method call:

  1. UI Context - Post a "GetAirplanes" message to the "UI Queue"
  2. Airport Context - subscribes to "UI Queue", sees "GetAirplanes" message
  3. Airport Context - Post a "AllAirplanes" message on the "Airport Queue"
  4. UI Context - subscribes to "Airport" queue
  5. UI Context - receives message "AllAirplanes" and updates HTML table.
1
domain-driven-design
This feels a bit backwards. Your UI wont be a bounded context. Your airport context should also not know about UI. I would say tour UI can either poll your domain for updates or subscribe to an "update" event in your airport context - SneakyPeet
It looks like you misunderstood what bounded contexts are. - plalx
@plalx UI is a bounded context in certain situations (p. 532, Implementing Domain Driven Design by Vaughn Vernon) - Andriy Drozdyuk
@drozzy I read that book many times, but I guess I overlooked that fact. I can't see for myself now because it's at work. Anyhow, sending a query through a message bus seems odd. You could simply expose web services in the Airport context and use a facade to access these services from the User Agent context. You would have to make sure to have an anti-corruption layer in place to avoid leaking irrelevant concepts from one domain to another. You can also look at CQRS. - plalx
@plalx Do you ever find having two different ports (rest + mq say) contributes to maintanace complexity or understanding? (I am worried other team members might see it as accidental complexity. I never done ddd before, that's why I am asking) - Andriy Drozdyuk

1 Answers

1
votes

A good approach to this is to build a read model from the events. A read model is just a simple dto that is suited to your ui. This is what you query. It should be super simple and optimised for the ui.

Generally you don't query your domain at all. It is responsible for handling commands and raising event messages that represent state changes.

You subscribe to these events to ensure your read model is up to date and ready to serve your ui.

I have a post that you may find helpful, in which I go into a bit more detail.

Over view of cqrs and event sourcing