How does Domain Driven Design handle Reporting?

Question

I found DDD being natural if I am working on a operational/transactional type of application. However I am always stucked in a reasonable way to handle reporting type of functions.

The reporting I am talking on is not bound to report generation, but also functions that perform comparatively complicated queries. (like, giving the summary of all orders that a trader did, or display the account summary for trading accounts having certain stock, etc). They can be simply some query or supporting function that is used together with those operational function.

For such functions, it is quite natural if we can perform join in SQL (or whatever query language), get the columns we are interested, and return the massaged result set. However, it seems such way not going that well with DDD: we need a extra special repository or having existing most-related repository returning a special "entity/value object" (which is the specialized resultset). These kind of special "entities" is not having any domain meaning in fact.

If we want to make use of the meaningful domain layer, that may creates a lot of extra lookups from different repository, plus a lot of aggregation work in the domain or service layer, which will easily cause horrible performance degrade.

I have also thought of having another "path" for these kind of function, which doesn't go through the "DDD path", having its own way to get the report data from DB, compose the results for display. However it is going to make the application unnecessarily complicated, and even worse, we provided an extra path so that developers that is more used to traditional DB-oriented development may tends to use this path even it is not appropriate.

I thought such situation is quite common (normally a big system will not contains operational but also reporting and enquiry functions), I would want to know how people is dealing with it?

Answer 1

In terms of DDD Reporting in most cases is a separate Bounded Context and a supporting subdomain where domain-driven design would be overkill. Remember the most important concept of DDD: Focus your modelling efforts on the Core Domain and implement everything else using the simplest possible solution.

Answer 2

We recently got into using DDD for system development. I had the same concerns as yours but eventually settled for Command Query Responsibility Segregation (CQRS) [Fowler, Young, Dahan]. While it is requires "the db path" for querying, I do not feel at all that it becomes tempting to do direct to DB for Commands (those that alter domain state). The separation is very clear - commands go through the domain, Queries go direct to DB.