This is an opinionated dictionary for CQRS. It focuses only on the critically important terms, while putting the rest outside the scope of this entire resource. This helps to reduce complexity often associated with learning the field of DDD/CQRS.

INCLUDED Dictionary Terms

TODO: Short definitions and links to internal wiki to be added

  • Aggregate
  • Bounded Context
  • Command and Query Responsibility Segregation
  • Domain-Driven Design
  • Event Sourcing
  • Eventual Consistency
  • Message (Command and Event)
  • Message Contract
  • Projection
  • Specification
  • View
  • Workflow


WorkFlow are just designed to model long running transactions as a series of short lived transactions. They are initiated by one event only, but this event might be of different types. The WorkFlow can thus be started using different entry points.
As a guideline, they produce commands and accepts events but that´s really up to the design.
The correlationId pattern is used to get the current state of the workflow when accepting a message.

EXCLUDED from the Scope

In order to keep things simple, some terms were consciously excluded from this resource. This is a subjective and controversial decision, but some sacrifices had to be made.

Fortunately, over the internet you can find plenty of definitions of these terms and lengthy discussions by experts. Please check out references for alternative points of view.

Business Component

Why Excluded? Business component and autonomous business component are terms that are frequently mentioned with the regards to DDD/CQRS. They are excluded from the scope of this this resource to avoid term bloat and abbreviation-based confusion with Bounded Context (critically important).

Distributed Transactions

Why Excluded? Distributed Transactions are a way to orchestrate transactions that span multiple resource managers (files, message queues, relational databases etc). This technology (most known implementation being Distributed Transaction Coordinator) works efficiently only within one machine or a small cluster. They are neither fit for distributed environments nor are needed there. Read Pat Helland's paper on Life beyond DTC for his critics of the distributed transactions.

Object-Relational Mapping

Why Excluded? Object-Relational Mapping is an old technology. It was born to solve object-relational impedance mismatch problem between object-oriented development paradigms and relational databases. Actual relational databases were created to solve persistence problems in times when storage and memory were extremely limited and expensive.

Life has changed slightly since then. Although relational databases are still a valid choice in non-critical systems, they are left out of the scope of this resource. Just like the ORM technology itself.


Why Excluded? Sagas have been defined in literature as a long-lived transaction that can be broken up into transactions but still executed as a unit. We don't want to steal the original definition and confuse people. Hence, workflow is used instead of CQRS Saga.

Service-Oriented Architecture (SOA)

Why excluded? SOA is a set of principles for designing and developing software in form of interoperable services (read more on wikipedia). It is considered to be redundant in DDD/CQRS approach and hence excluded from the scope of this resource.


Why excluded? Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems. This is completely irrelevant for this resource, just like term RESTful.

Thanks to Tom Janssens for reminding about this one.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License