Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Blog post on handling failures in domain services

  • Loading branch information...
commit 577ed500183fe9cadf1e3ad0a40336b94d10611a 1 parent e617636
Rinat Abdullin authored July 19, 2012

Showing 1 changed file with 40 additions and 2 deletions. Show diff stats Hide diff stats

  1. 42  Sample/Domain/IPricingService.cs
42  Sample/Domain/IPricingService.cs
@@ -22,8 +22,46 @@ public interface IPricingService
22 22
     /// <para>This is a sample implementation of a <em>Domain Service</em> for pricing. 
23 23
     /// Such services can be more complex than that (i.e.: providing access to payment
24 24
     /// gateways, cloud fabrics, remote catalogues, expert systems or other 3rd party
25  
-    /// services 
26  
-    /// </para> 
  25
+    /// services). Things that involve such complex computations or remote calls can 
  26
+    /// timeout, fail or blow up. If this is expected and possible, then we can build-in 
  27
+    /// compensation logic for that. </para> 
  28
+    /// 
  29
+    /// <para>The simplest option is to put such compensation logic within the application
  30
+    /// service itself (usually inside an aggregate hosted by such app service), 
  31
+    /// wrapping actual service call inside  WaitFor (google "WaitFor Lokad github") and 
  32
+    /// various retry policies, while catching exceptions and publishing appropriate events.  
  33
+    /// </para>
  34
+    /// 
  35
+    /// <para>Check out sample of LokadRequest (from .NET client for our forecasting API) 
  36
+    /// for a sample of retries 
  37
+    /// https://github.com/Lokad/lokad-sdk/blob/master/dot-net-rest/Source/Lokad.Forecasting.Client/LokadRequest.cs
  38
+    /// </para>
  39
+    /// 
  40
+    /// <para>However this approach can complicate aggregate code by unnecessary tech details.
  41
+    /// In this case we can push integration details into a separate bounded context. This BC
  42
+    /// will simply ensure that, whenever a command is received (e.g. "ChargeCreditCard")
  43
+    /// either "CreditCardCharged" event is published or "CreditCardChargeFailed" shows up
  44
+    /// within 5 minutes (timeouts are also handled). This also works for big-data processing
  45
+    /// scenarios, where actual data manipulation is performed by a separate bounded context. 
  46
+    /// </para>
  47
+    /// <para>
  48
+    /// This approach (of explicitly modeling integration) is worth it, when integration failures
  49
+    /// are both frequent and important for your domain (e.g. you charge your customers with 
  50
+    /// the help from 3rd party gateway).
  51
+    /// </para>
  52
+    /// <para>
  53
+    /// Such separate bounded context can use remote tracker to keep an eye on the timeouts
  54
+    /// and actually publish failure events if nothing happened for too long.  
  55
+    /// http://abdullin.com/journal/2012/4/21/ddd-evolving-business-processes-a-la-lokad.html.
  56
+    /// </para>
  57
+    /// 
  58
+    /// <para>Unfortunately, this topic is a bit too big for the A+ES sample for IDDD book. 
  59
+    /// However I will try to address it within Lokad.CQRS sample project, while adding
  60
+    /// rich domain model. </para>
  61
+    /// 
  62
+    /// <para>This is written by Rinat Abdullin on 2012-07-19 at Pulkovo. If you are reading this
  63
+    /// after more than 2 months since that date, and Lokad.CQRS project still does not address
  64
+    /// this issue, please kick me in the twitter or email.</para>
27 65
     /// </summary>
28 66
     public sealed class PricingService : IPricingService
29 67
     {

0 notes on commit 577ed50

Please sign in to comment.
Something went wrong with that request. Please try again.