CQRS not just for server systems - Conflict resolution

[Neylor Ohmaly Rodrigues e Silva]

In the "CQRS not just for server systems" talk, Greg Young talks about the "conflictWith" method, which is a method that is used to test if an event conflicts with another event. However it is not clear where this method should be

It should be on the Event class?

If it is on the Event class and the conflict resolution depends on some domain logic, it is ok to put it on the Event?

PS: Greg said that they talk more about this method on another video, anyone has a link to that video?

Thanks,

[Greg Young]

E conflicts with methods has a signature of

Event,event->bool

What goes in it is totally up to you. It can even be business centric (eg orders over £500 conflict with nothing). Or my personal favourite used the rank of the user :)

Greg

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Neylor Ohmaly Rodrigues e Silva]

So the method should be on the Event class. Something like this:

public class MyEvent {

  

  ...

  public bool ConflictWith(OtherEvent e) {

    return logic_for_conflict_resolution();

  }

}

right?

Em segunda-feira, 2 de setembro de 2013 19h48min48s UTC-3, Greg Young escreveu:

E conflicts with methods has a signature of

Event,event->bool

What goes in it is totally up to you. It can even be business centric (eg orders over £500 conflict with nothing). Or my personal favourite used the rank of the user :)

Greg

On Monday, September 2, 2013, Neylor Ohmaly Rodrigues e Silva wrote:

In the "CQRS not just for server systems" talk, Greg Young talks about the "conflictWith" method, which is a method that is used to test if an event conflicts with another event. However it is not clear where this method should be

It should be on the Event class?

If it is on the Event class and the conflict resolution depends on some domain logic, it is ok to put it on the Event?

PS: Greg said that they talk more about this method on another video, anyone has a link to that video?

Thanks,

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Greg Young]

You can do but I normally wouldn't. Most rules are pretty simple.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Neylor Ohmaly Rodrigues e Silva]

Where the "ConflictWith" method should "normally" be?

[Greg Young]

Depends on how many rules etc you have. I would normally make just one method as opposed to having it on every event class. That said if I had a ton of complex rules I would consider breaking it apart that way

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Neylor Ohmaly Rodrigues e Silva]

For simple rules, that single method should be part of a specific class of the domain or it should be in the repository?

Thanks for the answer and sorry for the dumb questions.

2013/9/2 Greg Young <gregor...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/hFEUMjuWGH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Greg Young]

Probably on its own in some kind of dumb service. If I found I had more than say 50loc in it I might consider refactoring

2013/9/2 Greg Young <gregor...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/hFEUMjuWGH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Peter Davis]

We found mostly only 2 or 3 categories of conflicts.  Like "by default events only conflict with themselves", "EventA conflicts with EventB and EventC", or "FooDeletedEvent conflicts with everything".  Factored out a ConflictResolver service implementation that just checks the annotations like @ConflictsWith({EventB.class,EventC.class}) or  @ConflictsWith(Object.class) /*everything*/.  Anything more complicated is definitely the exception not the rule.

Oh, and ConflictResolver is driven by the repository.  (Interface was provided by our framework - Axon.)

2013/9/2 Greg Young <gregor...@gmail.com>