Paolo Negri, CTO at Contentful, believes GraphQL can be used for large-scale domain modeling within digital transformation initiatives.

GraphQL is well on its way to matching REST API’s popularity, making the question of its future role extremely relevant, not only for the technical audience but for anyone leading or involved in the building of digital businesses or processes of digital transformation.

The Problem of Digital Businesses at Scale

When a digital business scales significantly, often there are multiple teams within multiple departments that need to collaborate with one another. This requires establishing areas where teams are completely independent, areas which need coordination and managing the interface between teams.

The challenge is really about team collaboration — bringing down the cognitive load and processes surrounding interfaces while allowing communication and business processes to flow easily through the entire organization. Such communication processes model the structure of a modern computer network (such as the Internet) rather than a system of siloed hierarchies.

To make things more complicated, the challenge involves two heavily interrelated, complex aspects: the organization itself and the technologies it uses. Both must not only be functional but also consistently designed in such a way that implementing changes to either should come at a relatively low cost.

Digital transformation is an umbrella term to describe the high-level process of redesigning an organization’s structure and processes in order to take full advantage of the possibilities of current digital technologies to deliver products, which themselves are completely or partially digital.

Domains as a Toolset to Untangle Complexity and Enable Teams

Software development has been working constantly with the challenge of bridging digital and the real world. Some approaches developed in this context can be elevated from that discipline to the wider topic of digital transformation, in a fashion similar to how Agile principles are now used to drive choices at a much higher level than what the original manifesto’s proponents had in mind.

The foundational book Domain Driven Design establishes the idea of using a Domain Model in conjunction with Ubiquitous Language in order to facilitate consistent and effective collaboration between domain experts and software developers.

The same exact concepts of Domain Model and Ubiquitous Language can be used to manage a fundamental aspect of digital transformation, which targets to have technologically-enabled teams that can iterate at a fast pace. It would be helpful to have a way of defining what a team would effectively own or work on, and how that team would interface with other teams.

Domains are very useful for this exact purpose — a team can be defined by the domain (or domains) that it owns. A further interesting step is to look at interfaces between teams as domains; where a team internally maintains a domain and is exposed to other teams’ interfaces that are also in the form of domains and constitute specializations or enrichment of the original domain.

Taking this concept further, you could model an entire organization as a compound of teams that take one or more domains as input and then perform transformations and actions in these domains. This will finally expose new domains as an interface with the other teams, who are subsequently able to, in turn, consume them as input.

It can also be noted how this approach can be applied not only internally to an organization but also at its interface, so the input and output of the organization itself can be seen in terms of domains.

This domain-driven design bridges the two key aspects of digital transformation—organization and technology. The domain concept has a clear, relevant role from business point-of-view as much as it is meaningful in terms of technical implementation. This is much superior to having teams that are conflicted by reasoning on the technical front, implementation-related concerns such as the services they own and run, and more abstract concepts from attempting to capture value brought to the business from a product standpoint.

Once a domain is defined, it becomes more intuitive to define its impact and role on current business dynamics and to agree on what is technically necessary to operate the domain.

How Domain-Driven Thinking Can Enable Fast Iteration

With an organization built around the concept of Agile Teams and the domains that they make available and operate, it is possible to easily identify what a new digital business initiative entails and how it can be achieved.

Teams can even define raw ideas in terms of the domains that it will be relying on. This way, we can identify what new domains need to be defined or if any rethinking of current domains is required in order to make the initiative possible.

Since domain definition is crucial to how the business and organization will work, business-relevant insights and awareness get raised across various levels. Leadership is able to have discussions that are less bogged down by mechanics (details on how things work) while teams get more insight into how their work relates to the language of leadership and business, and hence able to have a much clearer perception of what they are participating and contributing to.

To obtain and sustain a fast iteration pace in this setup, teams are technically enabled to repeatedly perform some fundamental actions that are: the definition and modeling of a new domain, deriving new domains from existing ones, operate changes on domains and finally exposing domains for user interaction.

Businesses Already Rely on The Ability to Deal With Domains

While organizations might not already think in terms of domains, they effectively are already relying heavily on implicit domain modeling used to implement current business processes and deliver on digital initiatives.

This means that many existing domain models have probably been documented in some form. Thus, the gap toward domain-driven is not as big as it may seem. There are activities closely related to domain modeling that are performed routinely by any business; such as structuring data that applications rely on, defining database schemas, and developing KPI systems and formal descriptions of processes. Most of the required change is at the level where teams reason and develop a culture, in which domain modeling is necessary in order to identify implementation needs.

GraphQL Is Key in Enabling Domain Driven Architecture

GraphQL is defined as “query language for APIs and a runtime for fulfilling those queries with your existing data.” It has spawned a technology ecosystem that serves a purpose much higher than just enabling querying of data.

GraphQL effectively derives most of its value by building on the foundation of schema definition; a higher level version of an entity-relationship schema definition that is more concerned with proper modeling and type definition. This is compared to database schema modeling, which is often concerned and distorted by technicalities of the database engine. This makes GraphQL a natural fit for domain modeling.

GraphQL also brings other capabilities such as mutations, which are the rules for how domain data can be changed. Mutations are also an example of how the discussion around GraphQL modeling practices is very active.

GraphQL is a tool that is able to closely reflect the conceptual domain model of a software ecosystem. It provides a standardized way of exposing the domain model’s APIs and defining the modality of interaction with the domain. With GraphQL being the effective, next-generation tool for modeling domains, teams that adopt it will almost certainly be at an advantage over those that don’t.

How GraphQL Enables Fast Domain Driven Iteration

This perspective allows us to look into the GraphQL ecosystem from a point of view that is different from that of evaluating it merely as a toolchain. In turn, that provides a great revelation that the ecosystem already produces tools that help move current architectures in the new pattern.

Support for the Definition of a Domain Model

This category could also be called a native domain model since it serves as a family of platforms and tools that facilitate the set up of a domain model from scratch. Within this category, platforms range from those like Contentful, that allows you to quickly spin up domain models for content use cases, to more generic platforms like AWS AppSync that enable the creation of more general purpose domains.

Exposing Data Sources as Domain Model

This category is about bridging existing data into the new GraphQL domain driven architecture—Prisma is a player in this space that allows the definition of domain models on top of databases and data stores.

Generating Domain Models from a Combination of Other Domain Models

Once domain models are encoded as GraphQL schemas, it’s possible to perform operations such as schema stitching that essentially allow a definition of domain models from a combination of other domain models. This is one of the most intriguing aspects in the context of digital transformation since it can play a key role in creating interfaces between teams or creating digital products built on existing assets and capabilities.

Exposing Domain Models for Human Interaction

Here lies the intersection between UI/UX and domain model—with a new wave of players such as GatsbyJS that embrace GraphQL and a modern frontend toolchain. This is an area where the domain model doesn’t quite end up as the central entity but, as the ecosystem evolves, a bigger role for the schema is to be eventually expected.

Propagating, Processing, and Distributing Changes of Domain Models and Data

All the above will make some wiring necessary for activity based on domain models and the data that they hold. There aren’t specific GraphQL players in this space yet, but there are two categories of event-driven tools and platforms that are likely to play an important role. Those include continuous integration toolchains like CircleCI, messaging and event-driven toolkits like Kafka, and analogous serverless platforms like AWS Kinesis and Lambda. This also serves as a playing field for new players, like Netlify, that blur the lines between continuous integration, deployment, and distribution, and could induce innovative trends in technical architecture.

The Perspective for the Future

There’s a need to define new KPIs and standard feature sets around domain driven architecture, and what facilitates iterations on them. In every category, be it e-commerce, content, payments, and billing, or CRM, there’s plenty of innovation to be expected in the transition from a packaged solution to a solution that enables digital product delivery on specialized domains.

Enterprise software architecture is likely to see a new innovation wave, similar to that of SaaS and cloud adoption, that will form new stacks through the establishing of next-generation tools and platforms.

Digital transformation can be facilitated in a way that’s much smoother with the use of domain model and ubiquitous language concepts. This is accomplished by giving teams within an organization a better, clearer view of set goals and how they can be achieved. GraphQL is key to supporting this as a valuable way of fulfilling data queries, and it does so efficiently since it’s built on schema definition as a foundation.

To get a fuller picture of digital transformation and the web, I have also written other pieces, on the understated innovative value of static site generators and how cloud computing is headed in the direction of utilizing GraphQL and going serverless, that tie into this one.

Paolo Negri

About Paolo Negri

Paolo Negri is the CTO of Contentful, which he co-founded in 2012. Contentful provides content infrastructure: a central hub to create, edit and manage content, and the tools to ship it to every digital platform. Before this, he built API-based game servers at Wooga, and has also led the development and scaling at Forward and Autoscout24.