CODEWITHSUNDEEP
javadomain-driven-designcqrsevent-sourcing
Bojan Vukasovic
Bojan Vukasovic

Reputation: 2268

Command Messages - classification design question

I'm trying to design one service using event sourcing. One use case is - when command arrives, I have to execute some logic and transform object from one MODE to other one. Now, the "problem" I'm facing is to decide between these two options for command messages:

Option 1: (put mode directly into name of the command message)

SetToManualModeCommand{
  int val = 22;
}
SetToAutoModeCommand{
  int val = 22;
}
SetToSemiAutoModeCommand{
  int val = 22;
}
SetTo...ModeCommand{
  int val = 22;
}

Option 2: (put mode as an enum inside single command message)

enum Mode{
  AUTO, 
  SEMI_AUTO, 
  MANUAL;
}

SetToModeCommand{
  Mode mode;
  int val = 22;
}

Do you see any drawbacks/benefits of any of these 2 options, or are they more less the same?

Upvotes: 0

Views: 62

Answers (4)

Eben Roux
Eben Roux

Reputation: 13246

My general approach is to not include classification as structure. Having classification as data seems to be easier.

Another example that is similar to yours would be different types of customers: GoldCustomer, SilverCustomer, or BronzeCustomer. A while later (2-3 years) the business may decide to add a PlatinumCustomer.

An enumeration may be better but for anything that is not fixed I would not use structure (neither class nor enumeration). Field positions in some sport may be an enumeration since these are fixed. If they change then it is significant enough to warrant code changes.

To that end I would have some domain concept represent the mode in a more generic/fluid fashion but YMMV.

Upvotes: 0

Roman Eremin
Roman Eremin

Reputation: 1451

See what you code wants. If command sending code is a switch statement that encodes your mode, and event consuming code is also a switch statement that decodes your mode, then just send a mode as a command/event payload.

If consuming code for each mode is in different places - then make it easy for each place to subscribe to right mode - make different events for each mode.

Upvotes: 0

Brad Irby
Brad Irby

Reputation: 2542

From the context you’ve given I don’t see a convincing argument either way. I know you’re talking about commands, not events, but try thinking about it from the event subscribers point of view. Is the significant event that the mode changed in some way, or that it changed to a specific value? In other words, would subscribers want a single ModeChanged event with details inside the event, or would some subscribers want just ModeChangedToManual and others just want ModeChangedToAuto, etc. You may consider the event storage system you’re using and how easy it is to create a filtered subscription.

It’s convenient (not required) that each command creates a single event. If subscribers would prefer a single event and you have 4 commands issuing that event it makes the system just a tiny bit more complicated, and those tiny bits tend to add up. If it’s better for subscribers that you have 4 separate events, then have 4 separate commands.

Upvotes: 1

Codescribler
Codescribler

Reputation: 2305

As a general principle - make the implicit explicit. Therefore make a command for each 'mode'. But I honestly don't think there is much in it.

Clearly what you actually do is very dependant on the context of the system you are building. How often do new modes get introduced?

I would say, however, that you should definitely have an event for each mode.

Upvotes: 0

Related Questions