Responsibility separation CQRS schema for [go] command query

The command query Responsibility segregation (CQRS) mode is an architectural pattern that separates the command that alters the state of the model and the query implementation of the state of the model. This is a pattern in the DDD application domain, mainly solves the DDD in the database report output processing way.

In an interview with Infoq, Greg Young spoke of "state transitions in Domain-driven Design", which Cqrs,greg explained by dividing the domain model into two types: status check, and state transition, maintaining a view of the current state.

In the client will be the new modification of data deletion and other actions and queries to separate, the former is called Command, walk the command bus into domain to operate the model, while the query from another path directly to the data operation, such as report output.

When a command comes in, load an aggregation aggregate object group from the warehousing repository, and then execute its methods and behavior. In this way, the aggregation object group is fired to generate an event that can be distributed to the storage repository, or distributed to the event bus events buses, such as the Java EE message bus and so on. The event bus will activate all the handlers listening for this event again. Of course, some handlers perform operations on other aggregated object groups, including database updates.

Because domain object operations and database preservation persist these two action separations, the data table structure can be loosely coupled to the domain object (Jivejdon source can display domain objects and data tables is no longer a one-to-one dependency, which is easily caused by using an ORM framework such as Hibernate), You can optimize the data table structure specifically for querying.

Furthermore, because events drive the state of the domain model, if you log these events audit, you will be able to replay some of the user actions to find the trajectory of the important state change, rather than simply relying on the data table field to show the current state, as to how these current states come from, you cannot know. When you get the aggregates from the database, you can also take out related events, called Event Sourcing, where the event source does not occur, but it can clearly explain the intent of the user operation.

Although this architecture is somewhat complex, there are many benefits, mainly the implementation of transparent distributed processing transparent distributed processing, when using events as the engine of state change, you can achieve multitasking concurrency, For example, with JVM parallel computing or event message bus mechanisms, events can be easily serialized and routed between multiple servers (EJB advocates for the anemic blood loss model, which is actually a cost-effective way to solve the serialization of a fat model when it is transferred between multiple servers, and now we do not serialize the model, but the events that change the model data).

Responsibility separation CQRS schema for [go] command query