CODEWITHSUNDEEP
domain-driven-designcqrs
erlangb
erlangb

Reputation: 533

CQRS design: nosql data view

This is a "language agnostic" question. I started to study the CQRS pattern.

I've a simple question. I'm supposing to have 2 different storage layer: one relational for the commands(Mysql etc..) and one NoSql (mongo,cassandra.. etc) for the "query"?

Let me explain a little example:

1) As a user I want to insert a "Todo task" Command: "Create Task" and will insert a new task into a database which have the User and the Todo tables.

2) As a user I'm able to see a list of created task Query: "GetTasks" that will return a "view" with a collection of task taken from a non sql table named "UserTasks" which have a user and a list of created task.

Is the right approach? I'm sorry if the language is poor, it's just a little example. If it seems a good approach (again, don't consider details) what is the best approach to keep updated the data stores?

I'm thinking to raise an event like "TaskCreated" and take the new task and insert those information in the nosql storage.

Thanks!

Upvotes: 1

Views: 308

Answers (2)

Codescribler
Codescribler

Reputation: 2305

While there are times when you may wish to store commands, you generally don't. Rather a popular approach is to store the domain events that occur as a result of the commands.This is referred to as Event Sourcing. This would make 'STOREA' a store of events or to put it another way, an event stream. 'STOREB' is typically referred to as the Read Model. It has a de-normalised structure optimised for read speed. It is kept up to date via de-normalisers which respond to specific events. A key point to note here is that there is often a lag between the event being raised and the read model being updated. This in my opinion is a good thing but needs to be thought about when designing the UI.

For more info take a look at CQRS – A Step-by-Step Guide to the Flow of a typical Application

I hope that helps

Upvotes: 0

ashic
ashic

Reputation: 6495

I can't really understand what you're looking for. but... typically, a command would be something that results in side effects. Queries don't cause side effects. GetTasks wouldn't really be a command, but a query.

Your "CreateTask" would be a command, which would result in the task added to the relevant data store(s). Your GetTasks query would retrieve that information from a datastore. It doesn't really matter if you're using a SQL or NoSQL store for this.

The "CommandStore" is typically the store that has just enough data to enforce invariants. In your case, what data is required for that? Is some information required to decide whether or not a task can be registered? For example, say, you have a requirement that a user can have at most 3 "todo"s. In this case, a table in the "Command Store" storing (UserId, Todo Count) is enough. You could also use (UserId, [TodoId]) - ie. store a list of todo ids so that you can gain idempotence. All other information about the user and tasks would be query data, and would be in the query store.

Hope that makes sense.

Upvotes: 0

Related Questions