DDD & The GraphQL Sweet Spot

In Domain Driven Design,  author Eric Evans suggests one way to reign in this type of growing  complexity: extreme discipline around the language used to describe the  problem and its solution. Choose nouns and verbs to describe sets of  related processes, problems, and solutions that are precise and  consistent, forming an “Ubiquitous Language”  that developers, users, and domain experts can all use to mean the same  thing. Evans goes further: the implementation should be an expression  of the Ubiquitous Language, ideally taking on a form where it is  self-documenting and sensible to a non-technical domain expert.

Object-oriented  programming languages excel at expressing the core concepts of DDD:  Entities and their relationships to one another, but the Ubiquitous  Language tends to fall apart at the API, where it is arguably even more  important. Consider the REST architectural style. By applying REST’s  Uniform Interface constraint (specifically its most opinionated  requirement: hypermedia-as-the-engine-of-application-state),  you may inadvertently reduce the ability to express your domain model  fluently. Other API technologies like SOAP XML-RPC keep the domain model  intact, but at the cost of significant complexity and limited  portability.

I believe GraphQL occupies a sweet  spot — it concisely expresses the domain model’s graph of relationships  without leaking implementation details while remaining simple enough to  share across different types and versions of clients. As in other  schema-driven API technologies, the GraphQL schema can be seen as an  expression of the Ubiquitous Language.

https://hackernoon.com/graphql-and-ddd-the-missing-link-4e992a26b711