How to expose read-only calculations from business domain model on back-end to front-end using CQRS? A Read-Model vs. Write-Model Issue

[Joerg]

I have two questions related to CQRS and Domain Driven Design (DDD).

As far as I understand the segregation idea behind CQRS, one would have two separate models, a read model and a write model. Only the write model would have access to and use the business domain model by means of commands. The read model, however, directly translates database content to DTOs by means of queries and has no access to the business domain at all.

For context: I am writing a web application back-end that provides calculation services for particle physics. Now my questions:

1.) My business domain logic contains some functions that calculate mathematical values as output from given measurement system configurations as input. So, technically, these are read-only queries that calculate the values on-the-fly and do not change any state in any model. Thus, they should be part of the read model. However, because the functions are heavily domain related, they have to be part of the domain model which again is part of the write model.
How should I make these calculation functions available for the front-end via my API when the read model, that should contain all the queries, does not have any access to the domain model?

Do I really have to trigger a command to save all the calculations to the database such that the read model can access the calculation results? These "throw-away" calculations will only be used short-term by the front-end and nobody will ever have to access the persistent calculation results later on.
It's the measurement configuration that has to be persistent, not the calculation results. Those will be re-calculated many times, whenever the user hits the "calculate" button on the front-end.

2.) I also feel like I duplicate quite a bit of data validation code, because both read model and write model have to deserialize and validate the same or very similar request parameters in the process chain

http request body -> json -> unvalidated DTO -> validated value -> command/query.

How should I deal with that? Can I share validation code between read model and write model? This seems to dissolve the segregation.

Thanks in advance for all your help and ideas.

[Joerg]

Hi there,

I have two questions related to CQRS and Domain Driven Design (DDD).

Also see my SO question here: https://stackoverflow.com/questions/60334923/how-to-expose-read-only-calculations-from-business-domain-model-on-back-end-to-f

[Rickard Öberg]

On Tue, Feb 25, 2020 at 11:50 PM Joerg <england...@gmail.com> wrote:
> For context: I am writing a web application back-end that provides calculation services for particle physics. Now my questions:
>
> 1.) My business domain logic contains some functions that calculate mathematical values as output from given measurement system configurations as input. So, technically, these are read-only queries that calculate the values on-the-fly and do not change any state in any model. Thus, they should be part of the read model. However, because the functions are heavily domain related, they have to be part of the domain model which again is part of the write model.
> How should I make these calculation functions available for the front-end via my API when the read model, that should contain all the queries, does not have any access to the domain model?
>
> Do I really have to trigger a command to save all the calculations to the database such that the read model can access the calculation results? These "throw-away" calculations will only be used short-term by the front-end and nobody will ever have to access the persistent calculation results later on.
> It's the measurement configuration that has to be persistent, not the calculation results. Those will be re-calculated many times, whenever the user hits the "calculate" button on the front-end.

Both the read and write model can be said to be domain models. They
are models about the domain. But one only handles reads and one only
handles writes. In my case they are both exposed through a REST API,
so write model commands are invoked by doing POST on forms, and read
model queries are invoked by doing GET on forms or following links. In
your case it sounds like, if you were to expose it as a REST API, that
is simply a GET form. Right?

> 2.) I also feel like I duplicate quite a bit of data validation code, because both read model and write model have to deserialize and validate the same or very similar request parameters in the process chain
> http request body -> json -> unvalidated DTO -> validated value -> command/query.
> How should I deal with that? Can I share validation code between read model and write model? This seems to dissolve the segregation.

What is the read model validating? It should only validate that input
parameters to the calculation is correct, right? Which sounds like it
would be quite different from the write commands. But the devil is in
the details, got example of the overlap?

/Rickard