We are planning a complete rewrite of a very complex project (10+ years, ~15 different application modules) and we would like to adhere to DDD and CQRS as much as possible but we are struggling to fit our needs.
The app is a data-analysis tool that basically stores data and allows the user to configure custom analysis\reportings. The key point is that writing logic (validation, business rules, etc...) is as much important as reading logic.
Many features are based on the flow: "retrieve data (from db) -> perform different processing on that data -> display it". This is a super common pattern we have throughout the whole application. Processing logic must happen in memory and cannot be stored.
The key point here is that processing logic is not just DTOs conversions. As we handle historical data, it evaluates many different engineering and mathematical models. For the business, this "computing logic" is core, as it is the writing side (i.e making sure the data stored is consistent, valid, and doesn't break any rule).
We work with .NET (C#), but I don't think that matters too much.
What we are failing to understand is how (if at all) DDD can help us here. We all know (correct me if I'm wrong) DDD focuses on writes and not reads. Queries don't follow the same flow and are simply executed against a DB and should not encapsulate any business logic.
Our concerns are about the fact that queries have to perform a lot of "business logic". They aren't plain and simple "get those entities paged". Splitting the business logic (reads and writes) into two different approaches (DDD on one side and something else for the queries) seems very odd to us.
Is there any literature\patterns for scenarios where write logics is as important as read logic and contains the same amout of "logic"? Is there a known way to make this work with DDD without having to write logic in different classes?