Question

Our architecture is divided in commands and queries its not fully CQRS but we try keep those things separated. Both use the same database. Let say that we have requirement that says: User may send message only to:

  1. its close friends who have messaging system enabled
  2. its close friends who are premium users
  3. to any administrator on contact list

We check those requirements when user tries to send message to a person, so domain rules are secured. However now we need to show list of possible message recipients to user and all of those rules need to be repeated on query side. And that bothers us.

Is this violation of DRY or is it ok? If new rule will be introduced it must be added in two places. Is there any nice way to handle such situations?

Was it helpful?

Solution

There are various ways to share the code. If you're in one database, than a simple view will probably do the trick. The query to limit potential addressees cannot be authoritative; only the command can do the final verification. The query just helps the user. The command would execute under some known transaction boundary to ensure the rule is followed.

OTHER TIPS

"We check those requirements when user tries to send message to a person, so domain rules are secured. However now we need to show list of possible message recipients to user and all of those rules need to be repeated on query side. And that bothers us."

How is that going to be repeated if you are using the same database for both domain and read models? Even if you are using one database for everything, on your domain and read model handlers you should abstract that with read only repositories. Also in relation to your mention about DRY, you will have that a lot in a CQRS architecture, since one of the aims is to be able to retrieve that faster without the need to do huge queries, so you will end with data repeated across diferent models.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top