The big role of GraphQL in domain driven design for architecture in digital transformation

The problem of digital businesses at scale

When a digital business scales to the size of significance, often there are multiple teams within multiple departments, division or regions 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 through the entire organization in a fashion that is closer to 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 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 enrichments 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 reasoning is particularly attractive because it bridges the two key aspects of digital transformation—organization and technology—with the domain concept, that 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.

Why 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.

Starting from a raw idea, it is possible to define it in terms of the domains that it’ll 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.

Due to how central defining a domain (and modeling it) in this framework is to how the business and organization will work, business-relevant insights and awareness get raised across various levels. Leadership are able to have discussions that are less bogged down by mechanics (details on how things work) while teams can 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 domain for user interaction.

Why business performance and the success of digital transformation projects already depend on their 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. The gap that needs to be covered in order to begin reasoning in a domain-driven way is not as big as it would initially seem. That’s because 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, and the implementation side is all about bringing domains alive by defining their models well.

How the GraphQL stack can be 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" and I’ve already discussed how 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 a entity relationship schema definition that’s more concerned with proper modeling and type definition compared to database schema modeling that is often concerned and distorted by technicalities of the database engine. This makes GraphQL a natural fit for domain modeling; it also brings other capabilities such as mutations, which can be seen as a definition the rules for how data belonging to the domain can be changed. Mutations are also an example of how the discussion around GraphQL modeling practices is very active—there’s an interesting blog post from commercetools on the topic.

GraphQL is a tool that is able to closely reflect the conceptual domain model of a software, and 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 the GraphQL ecosystem is shaping and how it enables domain driven fast iteration

What’s interesting in this perspective is that it allows a 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 he ecosystem already produces solutions that help move current architectures in the new pattern.

Support for the definition of a domain model

This category could also be called 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 allow 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 datastores.

Generating domain models from 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 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 usage 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.