Tactical DDD Patterns Continued

How about reports?

After reading the previous section, perhaps you will pose a question; how should we implement operations that allow searching for objects by their attributes other than keys? While you can get along without such queries in a domain layer, reports commonly need the flexibility to traverse a collection of rows, so the suggested trick will not work.

The answer to the above question is in a combination of CQRS and Event-Driven Architecture, which turns reports into aggregates. Specifically:

• Compose data necessary for a given report into a single CQRS read model, and treat it as an aggregate.

• When a user wants to view the report, retrieve the entire read model aggregate by its key, and display it on a screen.

• To filter report’s rows based on user’s input, narrow down the aggregate’s content in memory after retrieving it from storage and before displaying it on a screen.

• Keep the report-related read model up-to-date by employing event-driven architecture: subscribe to events that tell you when to refresh aggregate and regenerate the report’s content accordingly.

As you noticed, this technique still deals with a single aggregate by its key, so we have successfully applied the same minimalistic method to this uncommon situation as well. Therefore, we can conclude that the described approach is sufficient for advanced search scenarios, such as reports.