CODEWITHSUNDEEP
domain-driven-designcqrs
Arthis
Arthis

Reputation: 2293

One command for each state, or one command to rule them all

I am struggling with the analysis of a problem I am working on. I deal with a cleaning app where cleaning are scheduled, then done by some enterprise and finally controlled by the owner of the premises.

When the enterprise has done its part, it must send a command to the application telling either:

each of these might use different informations. So I was thinking of using 3 different commands to model it instead of having only one and adding a state.

But there is one level more of complexity , because there are 3 major kind of cleaning that an enterprise might perform and foreach of these, you might have different things to add to these commands (eg: number of seats to clean, or area and description).

Just with this it makes me already 9 cases to handle. I sense that decoupling all these is the right way to go because, it enables then more flexibility in the future.

But am I right thinking that these 3 are different things, should they not be only one big command like :

I quite do not like the thought of having an object half full because it covers too much things..

Thanks for your reading and your thoughts,

Upvotes: 1

Views: 73

Answers (1)

Oded
Oded

Reputation: 499062

You have made a good case for the decoupled approach - separation of concerns is a good principle to use.

If each command has a different meaning it should be modelled as a different object.

If you model each state change as a different object, you are on the way to having an event log and if you need it, event sourcing.

Having a method with (at least) 8 parameters is a code smell - it tells me the method does too much and will end up being very complex and difficult to maintain.

Upvotes: 5

Related Questions