0

I’ve got problem with DDD. I just started using it so I don’t have a lot of experience. There are two bounded contexts: Maintenance and Clients. Each Client has list of parts of an engine. In Maintenance are stored Companies whose occupation is repairs. Clients may choose preferred company to each part.
Administrator can suspend the company. There are changes in two aggregates. At the first, it change company status and next company should be removed from clients who prefer it. What is the best pattern to deal with it? I can create two handlers in aggregates but how I rollback changes when one of handlers throw exception?

Carlos G.
  • 4,564
  • 4
  • 34
  • 57
Max
  • 41
  • 1
  • 3
  • Should it really be removed? What if it's un-suspended again? Should it then really be gone for good from the client preference? :) – Joachim Isaksson Feb 17 '13 at 14:24
  • Ok. Maybe it isn’t the best example. I consider how to resolved situation when I have to do changes with two aggregates and handler may throw exception. – Max Feb 17 '13 at 15:43
  • 1
    Sounds like your bounded contexts need to be revised. Ideally you don't want to have dependencies between them. – stephenl Feb 17 '13 at 22:27
  • Out of interest, for the 2nd aggregate that contains a *clients preferred companies list* - what sort of domain logic do you actually have for this? Seems to me that you'd just have a view in your read model with the *preferred list* generated from events raised by your aggregates (you wouldn't have a preferred company agg). So in this case when a company becomes suspended then the CompanySuspended event would be handled by the *preferred list* event handlers and client associates removed... – Chris Moutray Feb 18 '13 at 12:01
  • To Chris Moutray: You are right. I don't have to store information about clients preferences in aggregate. They are stored in read model so i can use events. – Max Feb 19 '13 at 17:11
  • Have a look at the process manager (http://www.eaipatterns.com/ProcessManager.html) example in CQRS Journey. – Per Jan 23 '14 at 08:15

1 Answers1

0

It's looks like you need to revise your consistency boundaries in aggregates.

But if after revising you still need to change two aggregates in one transaction you can think about eventually consistent system and use domain events (but in CQRS you already do this, isn't it?).

Vaughn Vernon in his book "Implementing Domain-Driven Design" suggest next method for working with eventual consistency: aggregate publish domain event which is delivered to one or more subscribers. Each subscriber is executed in it's own transaction (so you still change one aggregate in transaction). If transaction fails (subscriber don't acknowledge success in timeout time) aggregate send message again or execute some rollback routines.

Since you are using Event Sourcing you can mark "failed" event as rejected and use Fowler's Retroactive Event mechanism.

Boris Tsema
  • 571
  • 3
  • 7