Should perform query at the point of time for the event or the actual time when working with CQRS for queue system?

I’m trying to implement CQRS for a queue system where user can join a queue by clicking a button. The system will tell the user if queue is full.

When the user click the button, it raised the command and triggered event like “user queued at 07:00 AM”. The handler for this event then (asynchronously) add a new participant to the queue. It also updates the full flag of the queue depending on how many participants in the queue. If the queue open for 1 hour, each participants get 5 minutes time slot, then it can hold 12 participants.

I would like to know which approach I should take when calculating the full flag:

  1. Use now(): calculate the latest value, always query the latest state of the queue. If the command is “user queued at 07:00 AM” and now is “07:10 AM”, the full flag reflects the condition at “07:10 AM”. Looks like will cause a problem when replaying the event.
  2. Use 07:00 AM: Calculate it based on the state at 07:00 AM. This means queries are more complicated: need to know how many participants at 07:00 AM.
  3. Use now() when handling the event then raising another event like “queue is full at 07:10”. This new event handler will eventually set the full flag instead of the current “user queued at 07:00 AM” event. Is event raising another event valid for this use-case?

CQRS and GraphQL



I have a CQRS domain with requests, authorizers, handlers, response objects, entities, filters, pagination.

It only depends on:

  • external services (email, other APIs, etc…)
  • a database/persistence layer
  • a way to retrieve the current domain user logged in


This CQRS domain is called from a web API that exposes 2 things:

  • endpoints for reading files
  • an endpoint to access a GraphQL schema


The GraphQL resolvers and controller actions only send requests to the CQRS domain. Each request represents an atomic use case (e.g. “I want to get the invoice PDF” or “I want to create a new invoice”).

So my controllers and GraphQL resolvers are very thin. Great.

The problem

Many problems arise though:

  • I’ve created a bloated code base because almost every GraphQL type has a corresponding domain type and its corresponding mapping profile (assuming Automapper)
  • The code has increased of about 30% – 40% overall and it’s difficult to follow the flow of data
  • All this mapping is extremely error prone
  • I often need to map back from CQRS requests to GraphQL inputs to determine the original input field path of the error that was returned by the CQRS handler/validator


On the one hand it’s great to have a common request -> handler -> response pipeline for all of your use cases so that you can implement cross cutting concerns and enforce them at the beginning of the pipeline, on the other hand I’ve lost the ability to clearly follow through the flow of control.

What am I missing? How is a bloated and complex code base better than a simple straightforward “business logic in controllers / graphql resolvers” logic? Isn’t all this mapping a violation of DRY (for example adding a field to an entity requires at least 3 classes to be modified)?

In a DDD CQRS API, is it preferable to have a separate DTO per query or per representation of a resource?

I am in the middle of starting up a new project and just wanted some reassurance as to which approach to DTO’s returned by the read-side was easier to maintain in a real world application with reasonable complexity.

I realize with a DTO per query, it would allow for a specific query’s response to diverge from the others more easily in the future. However, common properties between that query and other queries would require changes in multiple places (e.g. the same resource could have multiple queries in the form of GetById, GetAll, GetByStatus, GetBySomethingElse, etc.) and there is more repetition.

If a DTO is created per representation of a resource, a GetById might return a DetailedDto with many properties, while a GetAll might return a SummarizedDto with fewer properties. This would require less changes for common properties and diverging queries would just require a new version of the DTO to be created. The biggest disadvantage to this approach is that I’m terrible at naming classes and coming up with words, so “Detailed” + “Summarized” is the extent of my imagination.

I’m leaning towards refactoring my first attempt at writing this application from using the “DTO per query” to the “DTO per representation” approach. Are there any benefits to sticking with the “DTO per query” or is “DTO per representation” a good way to go?

DDD and CQRS – Define an entity for Scheduling use case

I have a use case of scheduling a person to some work for some time range. Eg. A service for assigning a person A to work for time range X to Z in location C.

The only constraint it has, is one person cannot work on 2 things at same time. Eg. if person A is assigned to work in time 2019-07-21 to 2010-07-25, then person A cannot be assigned to any other work in that time. Eg. Person A for time range 2019-07-23 to 2019-07-27 should not be possible.

I am trying to make a service for it using domain driven design which would assign a person to some work. The entity I thought would be something like:

class Assignment {     PersonId,     startTime,     endTime,     location } 

Now, I wanted to make sure that if I found a entry in my database for Person A in some time range, then the call to create an entry for Person A in time range that is overlapping with the existing ones should fail.

Since, I am using CQRS model with DDD, so I don’t want to make a query to my database asking for all the assignments for that person. This may not always be recent data because of eventual consistency in CQRS model. I know in my primary key, PersonId would be there but I am not sure how can I use start and end time in it.

Any suggestions what I can do to achieve my goal for this? Is doing DDD and CQRS not a good idea in this? Or there is a better way to model this entity so that I can achieve my goal.

CQRS sequential numbering of business documents

I am currently building a microservice-based system to learn CQRS/ES, Docker, AMQP and all the other goodies that goes with it.

I have never asked a question online before as I am usually pretty good at finding answers to my queries by reading what that others have asked.

This time, I am stumped by what seems to be very simple.

Business documents such as invoices, purchase order, credit memos, etc. usually have an identifying number. (i.e. Invoice No.: 5707)

My question (finally) is how would I produce a sequential number for each of these types of documents in an event-sourced system?

I was thinking of making a service. Then, perhaps make it an aggregate in my domain and possibly even event-source the aggregate as well.

Would it be better to make a service and inject it into the command handler for the CreateInvoice Command?

Perhaps it would be better to derive the next number by querying the event store for the highest-most numbered aggregate.

I’m concerned about race conditions where an invoice number may inadvertently be duplicated or skipped. What is the best practice for this?

Thank you for your time.

Same events for different aggregates in CQRS?

I’m developing an application using CQRS + ES.

Now I have 2 aggregates which are technically almost exactly the same, only they are different concepts in the domain. Therefore I will separate them into their own aggregates, but I could still use the same events for both aggregates. This would save a lot of work and pointless complexity in the application. Basically they are the same class that has only been separated for DDD sake.

Would there be a problem with this design? The aggregates themselves are responsible for maintaining correct state, so that would not be a problem. The read model does not deal with aggregates anyway, and it doesn’t care about the (small) distinction between those 2 aggregates.

Aggregate classes would look similar to the following:

// Aggregate 1 public class Page : AggregateRoot {     public Page(string id, ...)     {         this.Id = id;          // Same event for different aggregates.         ApplyChange(new ContentCreatedEvent(...));     }      // etc. }  // Aggregate 2 public class Asset : AggregateRoot {     public Asset(string id, ...)     {         this.Id = id;          // Same event for different aggregates.         ApplyChange(new ContentCreatedEvent(...));     }      // etc. } 

Storing within the domain use CQRS?

Assume we’re building a fleet management system that is monitoring telemetry on a fleet of cars. Important telemetry include like location, speed and engine temperature. Metrics are mostly dynamic and depend on what sensors they want to install (e.g. vibration, tyre pressure, weight sensors).

Metrics are viewed as potentially different individual streams of data with different periods of updates. e.g. speed might be updated twice a minute, whereas tyre pressure might be updated once an hour.

The are two primary use cases – viewing the current state of a vehicle and being able to dig into specific historical metrics (e.g. graph engine temperature over the past 48 hours).

My domain looks something like:

Vehicle (aggregate root)    |--> Metrics (value object)      |--> Metric (value object) 

This gives you the latest state of the Vehicle.

However, as mentioned, a valid use case might be to graph engine temperature and speed over the past month, which, in this case could equate to thousands (or tens of thousands) of data points.

One approach is to do something like the following:

class Vehicle {   Metrics metrics;   @Transient List<Metric> historicalMetrics; //Don't save this as part of Vehicle    updateMetrics(Metrics newMetrics) {     this.metrics = this.metrics.merge(newMetrics);      this.historicalMetrics.add(newMetrics.asChanges());   } }  class VehicleUpdater {   updateVehicle(UpdateVehicleCommand command) {     vehicle.updateMetrics(command.getNewMetrics());;   } }  class VehicleRepository {   save(Vehicle vehicle) {;      if (this.vehicleStore.hasHistoricalMetrics()) {       this.historicalMetricsStore.saveAll(this.vehicleStore.getHistorialMetrics());     }   } } 

There isn’t really much use for historical metrics within the Vehicle domain itself. There is use in showing it to the user for graphing and diagnostics purposes as well as potentially using it as part of a Rules Engine domain (not sure if this falls under the Vehicle domain or is separate) to raise events (e.g. preventative maintenance).

If the data should indeed be part of the domain, what approaches should I take to store all the historical metrics. Would they live within the Vehicle?

However I’m not actually sure how I would query for historical metrics. I obviously wouldn’t want to hydrate historical metrics for the Vehicle when loading it, since, in most cases, they aren’t relevant.

What I could do is something like:

class Vehicle {   List<Metric> getMetricsFor(String metricName) {     return this.metricRetriever.loadMetrics(this, metricName);   } }  class MetricRetriever extends DomainService {   loadMetrics(Vehicle vehicle, String metricName) {     this.repository.loadMetrics(vehicle, metricName);   } } 

However, in most cases you’d want to filter the metrics (e.g. within a time range or numbers within / outside a range, etc), which is leading me to consider whether I should store this data within the domain or just consider the historical metrics to be a query model and use CQRS to persist it separately?

If I take that approach, however, the query / read model will have historical data that isn’t part of the domain model. It won’t simply be a more efficient way of storing the data. Not sure if this takes it beyond the intent of CQRS?

TradOffs between Testability and Performance for CQRS Pattern

My team has recently decided to adopt the CQRS pattern similar to the one used in the famous Microsoft EShopsOnContainers repository. In this solution, the queries are made in Query classes using Dapper and Commands are done in command handlers using EF Core.

The queries that I am doing on my domain are quite complex and require a lot of filtering of the data. Without using LINQ. I am relying on using purely dynamic SQL statements (not my strong point) to query my domain model with multiple WHERE clauses etc.

This approach would make it extremely hard to unit test my queries.

Here are the two approaches I am considering:

Approach 1:

string sql = @"     SELECT * FROM [dbo].[vw_LogisticsManagement]      WHERE ([Status] NOT IN @WorkOrderStatuses )     AND ([PickupDate] IS NOT NULL)      AND (0 = (DATEDIFF (day, [PickupDate], getdate()))     AND (0 != (DATEDIFF (day, [CheckInDate],  getdate())))     ORDER BY [PickupDate]";  //Add parameters etc... var result = await connection.QueryAsync<viewModel>(sql, parameters); 


  • Very Performant


  • Difficult to test
  • Difficult to write (for someone without much SQL experience)

Approach 2

string sql = @" SELECT * FROM [dbo].[vw_LogisticsManagement]  var result = await connection.QueryAsync<viewModel>(sql, parameters);  var wos = result.Where(wo => wo.PickupDate.HasValue                 && wo.PickupDate.Value.Date == DateTime.Now.Date                 && wo.CheckInDate.Value.Date != DateTime.Now.Date                 && wo.Status != Status.Shipped                  && wo.Status != Status.PartiallyShipped)                 .OrderBy(wo => wo.PickupDate).ToList(); 


  • Very easy to write (someone with a lot of LINQ experience)
  • Easy to test filters: I could mock the result that Dapper returns (no need for in memory db) and then have a predefined list that I could apply the filters using LINQ and have an expected result


  • Not as performance. Enough to even matter?

So basically I am trying to weigh out the pros and cons of each, in my opinion testability outweighs the potential performance boost in this case, however not everyone from my team would be likely to agree.

Ultimately approach 1, with proper testing in place would be ideal as many of the queries I am dealing with are far more complicated.

Do we need two Entities with CQRS without event sourcing and using JPA?

So I am trying to implement DDD and CQRS (without event sourcing). I am need of clarity about the implementation details (Spring + JPA).

DDD with multiple small aggregate roots require @Entity classes with ID for maintaining relationships than having explicit relationships. As per Effective Aggregate Design by vaughn vernon

My questions is If I want to implement a simple CQRS do I need to duplicate all my JPA Entities for both Read and Write.?

I am going with this.

  1. Separate Read/Write Controllers
  2. Inject QueryService and CommandService into respective controllers so as to have clear hand off in project structure
  3. In ‘Domain‘ folder I maintain my Aggregate Entities (Also JPA Lazy loading) and Aggregate Root Repositories.
  4. In my Infrastructure I need to maintain Almost same Entities (JPA Eager loading?) Or Should I just write plain simple SQL queries using SpringJdbcTemplate
  5. Have my QueryService inside my Infrastructure code.
  6. Have my CommandService inside my Infrastructure code where I will call domain repositories and domain services (as in here ddd by example) and call Audit tables (simple events)

(without event sourcing because we cannot support that technology and we are short on time and new to DDD and CQRS)

My question on Item 4) and if writing in queries vs alternate set of JPA entities. If queries what JPA technologies are famous libraries will help to fetch aggregate root’s child entities easily? I know there is a trade of but need your thoughts a bit of decision points.

Are separate controllers used when adopting full scale CQRS?

I understand there are three flavours of CQRS:

1) Separate models only i.e. a domain model and a read model. 2) separate models and repositories. 3) Separate models; repositories and physical database. 

Is there ever a scenario where the controllers are separated into read controllers and write controllers? I have never seen this, however I am sure I once saw a diagram, which indicated separate read and write controllers.

I realise that the application will still work in the same way regardless of whether the controllers are separated. I am asking from the perspective of the principle of least astonishment.