The increased interest in exposing APIs to external partners has caused some headaches in building a consistent and cohesive set of APIS.
We have been maintaining legacy SOAP or REST Like APIs that still provide value to our consumers but have been considering GraphQL as a way to expose capabilities and features in a unified way.
While GraphQL has been primarily considered for the flexibility of the query language, we saw an opportunity to preserve our domain driven design architectural approach in building reusable modules to allow for Graphcomposition.

• Why GraphQL: Customer Centricity, Consistency, Extensibility
• Composition and Separation of concerns: Domain Driven Design calls for bounded domains while experiences need composition
• Building an experience graph: GraphQL Components, Apollo Federation