Welcome to my hell if you have to do this. ^.^;
/me works with an ancient Oracle database that was apparently designed by intellect-less committee…
Avoid it if you can!
If you cannot though, look at Absinthe. I’ve been hiding the hell behind it’s GraphQL interface and I make GraphQL calls from in-server to in-server, it has become an excellent ‘Context’ in the system for data calls distributed across everything. ^.^

I fully understand where you are coming from … but at the same time we have to acknowledge that from a beginner’s perspective setting up boundaries to isolate contexts while at the same time violating these boundaries with SQL joins creates a bit of cognitive dissonance.

The only way to remove that is to emphasize:

• contexts serve only the domain
• while reports/analysis/intelligence are legitimate user features they typically aren’t considered part of the core domain
• therefore reports are a concern separate from the core domain (and the goals contained therein)
• therefore SQL joins for reporting purposes aren’t viewed as violating any boundaries**
• and ultimately those reporting SQL joins need to be considered a “shortcut” because that approach to reporting simply doesn’t scale. The perception of boundaries being violated is gone once reporting is moved to a separate database (not with a mirrored schema - but with a data warehousing schema).

**However there still is contention in the sense that whenever you change the context’s schema you also have to update your reporting query.

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)

• 1. Really DRY
• 2. The Tower of Coupling
• 3. DRY vs. WET