title: How does Domain Driven Design handle Reporting?
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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?</p>