Actually there is a reason the OLTP vs OLAP dichotomy evolved. Your domain runs against a set of schemas on the online transactions processing systems side while your reporting, analysis, and intelligence runs on the online analysis processing side - typically reorganized in star schemas which are optimized towards the needs of data warehousing. So for reporting purposes data is duplicated from the OLTP system to the OLAP systems (Philip Greenspun: Data Warehousing for Cavemen (1997), Data Warehousing (2003)).
So it wouldn’t be too outlandish to suggest that for reporting purposes data should be “exported” to separate reporting schemas. In Phoenix when running multiple contexts against the same database one has the “luxury” of using a SQL join - but at the same time one has to be aware that one is engaging in an integration database.
When a context is promoted to a microservice this has to stop because an integration database violates service autonomy (a notion of “context autonomy” is probably appropriate as a context is all about cohesion). The typical solution to serve reporting needs is an Event Data Pump (Building Microservices p. 98) - while conducting it’s responsibilities each domain microservice emits events that are processed separately to be included in a reporting database - and that reporting database is used by the reporting service.
One interesting thing about contexts is that there are times where contexts legitimize violating DRY - but only when necessary in order to promote loose coupling because DRY can lead to tight coupling.
Development By Slogan with DRY (2015)
