Patterns, Principles, and Practices of Domain-Driven Design

26 Queries: Domain Reporting

WHAT’S IN THIS CHAPTER?

• Guidance on building reports that aren’t overly coupled to domain structure
• Building reports using existing domain services
• Building reports that bypass the domain and hit the database directly
• Building reports in applications that use event sourcing
• A discussion on the trade-offs involved when choosing between reports that belong to a bounded context and reports that need to integrate data from multiple bounded contexts

Wrox.com Code Downloads for This Chapter

The wrox.com code downloads for this chapter are found at www.wrox.com/go/domaindrivendesign on the Download Code tab. The code is in the Chapter 26 download and individually named according to the names throughout the chapter.

Software systems are built to support the needs of the business. Not only do these needs include revenue-generating functionality, but they also include the ability to assess how well the business is performing. This is the role of reports: to track important metrics and key performance indicators (KPIs) like sales, financial targets, and customer satisfaction. As you’ve seen so far in this book, there are many ways to build a system when applying Domain-Driven Design (DDD). Equally, there are many ways to implement reporting.

Choosing how to implement reporting in your applications involves considering familiar trade-offs: speed of development, maintainability, performance, and even scalability. Sometimes you can simply create a new web page ...