Domain Events Scenarios Question RRS feed

  • Question

  • A subset of my app consists of:
    - WCF NotificationService (for Duplex Communication with Silverlight 4 clients) -> in infrastructure layer
    - WCF Rest OrderService (SubmitOrder, DeleteOrder, ...) as façade/entry point for html/javascript/jQuery and Silverlight clients -> in application/service layer
    - class library with Order entity class -> domain layer
    - html/javascript/jquery clients for entering orders
    - Silverlight client for 1) automatically getting the orders when their OrderStatus has changed) and 2) to perform CRUD-Order- operations

    Purpose: when an order status changes automatically my Silverlight clients get notified, using Duplex Communication, with the Order.

    The options/scenarios to achieve this I can think about are:

    1 - The NotificationService 'Subscribe' method/operation (the method called from the Silverlight clients to subscribe) subscribes to the OrderStatusChangeEvent (raised in the Order entity-class - defined in Status property of Order class) and performs the necessary actions when this event is raised.
    2 - The OrderService methods/operations (SubmitOrder, DeleteOrder, ...) subscribes to the OrderStatusChangeEvent of the Order class (raised in the Order entity-class - defined in Status property of Order class), and when this event is raised the eventhandler (for this event) in the OrderService class calls a method in the OrderNotification service that raises an event that the Silverlight client must be updated (using Duplex Communication) and the respective method updates the Silverlight client (based on the List-Based Publish Subscribe pattern (

    Which one of the 2 seems the most best DDD practice? Or are their other better solutions?

    Tuesday, December 21, 2010 11:25 AM

All replies

  • The second option is better , if there is event action that is initiated by the server. Please do proof of concept in live customer environment and test the application thoroughly with live different possibilities , so you can come to a good conclusion.


    Tuesday, December 21, 2010 3:42 PM
  • For me it depends on the behaviour you're modelling. If you're only interested in 'something has changed' then either will do. However, I would imagine that you probably need to model specific behaviour, e.g. ProductWasCancelled, NewProductOrdered, ExistingOrderAddressChanged. In that case something that woud allow separate events to be subscribed to?
    Saturday, January 22, 2011 9:23 PM
  • Thanks.

    In the latter case (model specific behavior): what would be a good approach?

    Sunday, January 23, 2011 8:54 AM
  • Probably only subtle changes, you can still go with a single subscribed event if the arg is specific. But I think I'd prefer one per domain event
    Sunday, January 23, 2011 9:56 PM