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