On page 324, you talk about domain events and an example of how the Recommendations Bounded Context react to an event happening inside another Bounded Context.

The behavior that you mentioned in the domain layer can be reflected on the UI also. For example, I go to Amazon website and add a product to the shopping cart. As soon as I have done that I should see some recommended products at the bottom of the cart. In a NON-REACTIVE traditional application, to get the recommended products, the web site has to do an RPC call to a service called RecommendationService (WCF or REST). Is the UI expected to behave this way, call it NON-REACTIVE where the state on the UI is not consistent with what is in the system and does not have to be reactive. And it expects the user to do a refresh to see the new recommendations?

A few questions on this subject:

1. With DDD, is the reactiveness expected only in the business domain and not on the UI?
2. What is your recommendation to expose the domain behaviors to the UI?
3. Do you suggest a messaging infrastructure is needed in the domain to reflect the state changes to the UI like SignalR or Websockets?

Hi,

Good questions again.

1. Reactive principles do indeed extend to the UI and user experience. If you have a reactive domain that is firing events, and you can handle those events by updating the UI, you should definitely consider doing that if it provides a better user experience.

Reactive principles are about providing scalable event-driven software systems, but they are also concerned with how these benefits concepts provide benefits to your end-users.

2 & 3 There are multiple ways to achieve this, but in general I would recommend looking into websockets based approaches like Signal R.

One option is to raise events from your domain that are handled in the service layer. Inside the handler you would pump data down a websocket. We were going to show an example of this in the book, but unfortunately we had to reduce the page count. You can still find the sample code in the history on github though: https://github.com/NTCoding/PPPDDD/b...rderService.cs

Another option is that you could use a domain service contract. You could have an interface in the domain, something like IXXNotifier, and the implementation would live in the service layer. The implementation would send data down a websocket to the UI.

I will refer that example. I think I have see a similar pattern from Julie Lerman on her training in Pluralsight.