How to handle reporting with Domain Driven Design?

A pretty common question regarding Domain Driven Design (DDD) is how to handle reporting functionality in a system using a DDD-approach. As in most cases, the answer is "it depends".

If what we are aiming for is easy to change reporting I would transfer data into a BI-system and run reports from there. There is absolutely nothing to gain in designing our own BI-tool. There are plenty of them in the market, and in combination with some common data warehouse design patterns they do a good job both extracting, storing and providing easy prepared and ad-hoc reporting. If we do not need a fancy reporting interface just a separate relational database schema would do for running some SQL-queries. The key is to keep reporting separate from the business system. This is a good rule using DDD or not.

If it is more of "a small summary" or some accumulated totals that should be shown inside the business application I'd try to keep it inside the domain model. Most values, just like any attribute, would fit nicely inside an entity. E.g. if we need to calculate an OrderSummaryByStock, it might be placed as Stock.runningOrderSummary(). This makes it readable right of the entity it belongs to. If running into performance problems I'd look into keeping those numbers up-to-date as part of the command or update transaction, storing the accumulated numbers in the database, as part of the entity.

If you see overall problems with read performance due to multiple reads per write I would consider a CQRS-approach (with separate read-views kept up-to-date by events exported from the domain model as it gets updated), at least for the views in problem.