Domain Driven Design or DDD for short is a huge but interesting topic. It has many complex subjects focused on business and technical perspectives. In the technology industry, people always talk about how both perspectives should work together in order to give the business benefits. However, that is not an easy task and it is when DDD appears in the scene. In this course, you are going to learn the most important concepts of DDD. You will see some concerns, techniques to model, how DDD can be implemented using hexagonal architecture and many other amazing concepts.

Domain Driven Design (DDD) Made Easy

Once something is executed in a domain and has produced whatever event, a user may want to know what happened in the system. Queries are what enable the possibility for a user to receive information from a system.

## What are queries? 
Queries are the third of the three activities that can occur in a domain, and it is part of the **Command Query Responsibility Segregation (CQRS) pattern**. They represent requests a user does in order to receive information about a domain. Typically a system exposes some interface that enables the possibility to look for information. Also, a query should always return a response with information when it exists.

It is common to implement systems oriented to **CRUD**. They basically execute create, read, update and delete operations. In the case of queries, they are oriented to Read. System state should not change when executing a query.

### Queries are idempotent 
Queries should be **idempotent**. It means queries should not change the state of the system. In other words, no matter how many times a user requests information, the system should always return the same information. It is worth mentioning responses must be the same as long as there are no changes in between the queries. When a command is executed in between two queries, it will cause the second query to return a different response. Let us understand this behavior by an example. The following image shows how two queries are exactly the same when there are no changes in the state in between them. Also, they do not change the state either:

# What are queries? 
Queries are the third of the three activities that can occur in a domain, and it is part of the **Command Query Responsibility Segregation (CQRS) pattern**. They represent requests a user does in order to receive information about a domain. Typically a system exposes some interface that enables the possibility to look for information. Also, a query should always return a response with information when it exists.

It is common to implement systems oriented to **CRUD**. They basically execute create, read, update and delete operations. In the case of queries, they are oriented to Read. System state should not change when executing a query.

## Queries are idempotent 
Queries should be **idempotent**. It means queries should not change the state of the system. In other words, no matter how many times a user requests information, the system should always return the same information. It is worth mentioning responses must be the same as long as there are no changes in between the queries. When a command is executed in between two queries, it will cause the second query to return a different response. Let us understand this behavior by an example. The following image shows how two queries are exactly the same when there are no changes in the state in between them. Also, they do not change the state either:

Learn how queries enable a user to receive information from a domain.

Introduction

Mapping Domain to Model

Domain Activities

Domain Objects

Domain Abstractions

Hexagonal Architecture

Queries

What are queries?