Comments on: Brownfield CQRS part 1 – Commands

By: Tomas

Tomas — Fri, 23 Jul 2010 21:21:50 +0000

@seagile: do you mean that the client should provide the correational id and then wait for an event from the server? Isn’t that just a work around for request/response?
@andy, @richard: seems like you having the same discussion but with a different example. I think there will be situations where you want to provide metadata, like transaction id or login token. Do you really want to use CQRS on those kind of commands/operations? I really think it is an interesting pattern but I see some situations where it seems to make things more complex than they are.

By: CQRS Resources - The Developer Day

CQRS Resources - The Developer Day — Wed, 21 Jul 2010 21:37:17 +0000

[...] the answer by Udi Dahan. Clarified CQRS by Udi Dahan CQRS a la Greg Young by Mark Nijhof Brownfield CQRS by Richard Dingwall. Transitioning from DDD lite by Julien [...]

By: Andy

Andy — Tue, 20 Jul 2010 20:54:48 +0000

But is it not wrong to ask the query side for a token because then you change state (allocate new token). Feels like you want to have a “LoginUserCommand” but it feel wierd…..

By: Richard

Richard — Tue, 20 Jul 2010 09:02:10 +0000

@Andy: you could ask for a login token (query) then supply that token with each command sent to the server, and finally send a command to invalidate the token on logout.

By: Andy

Andy — Tue, 20 Jul 2010 08:57:46 +0000

How would you implement (using CQRS) a standard website login (username/password) activity?

A login is something that has to be performed without delays to not annoy the users.

Would you send a login command and then poll the query side for “login ok or failed?”. Will that not be pretty inefficient and take long time to login?

or would you store a “username/pwd” hash on the query side that the client queries?

But when you do login you want to do some logic as well…..

any thoughts?

By: seagile

seagile — Mon, 19 Jul 2010 22:13:59 +0000

@Tomas You could specify a correlationid and wait for response messages with that correlationid (one of those response messages could carry the transaction-id). I’d do that in a an async fashion, which would make it a basic saga I guess.
The other question you could ask yourself is if the transaction-id could not be determined on the calling side? Now, I never worked with PSPs before, so I may be out of my depth here ;-)

By: Tomas

Tomas — Mon, 19 Jul 2010 21:07:19 +0000

Lets say you’re a payment service provider (PSP). When creating/executing a transaction you would have a command like CreateTransaction or similar. How should you return the transaction id from such a command. Or should you first make a query asking for a transaction id and then use that id creating/executing your transaction?

By: Richard

Richard — Tue, 22 Jun 2010 14:15:35 +0000

@Matt: haven’t had a look at Agatha. I know WCF doesn’t support fully-generic parameters due to SOAP limitations.

By: David

David — Fri, 18 Jun 2010 17:57:25 +0000

Excellent article, I look forward to the rest of them however, in regards to the third reason to have a command DTO as apposed to a single parameter;

“Adding another parameter to the command (say, for example, an optional reason for cancelling) would require you to change the signature of the service contract. Ading another property to a command object would not.”

In either case, if you add a parameter to the service contract or add a property to the data contract of that service, the signature of the service in effect has changed (logically not binary). In both instances you would have to take into account versioning of service contracts and/or data contracts if you want, or just make sure all clients have the updated data contract (DTO commands) used by the service or the service contract (single parameter commands) itself.

By: Matt

Matt — Thu, 17 Jun 2010 23:10:46 +0000

@seagile: true – that is possible. you are correct there would be a smell, albeit not a good one. :)