Domain Dictionary vs. Domain Driven Design?

TL;DR

It is suggested to use a corporate domain dictionary as an input stream to the strategic domain driven design. The purpose is to keep the ubiquitous language of various bounded contexts in sync but decoupled.

The Problem

When the data model of a service, a database or an API grew without or with a weak architectural design, its terminology often becomes confusing. Attributes or entities were created on the fly by a developer without having the big picture in mind. This architecture style is quickly implemented, but not particularly sustainable.

Let's check the following example:

This design shows one very good thing: The database and the APIs of both services are well decoupled, at least on the data layer. 

But what happens if someone of the customer support department wants to check the database for the attribute "surname"? What if a third application is developed and needs to access both interfaces? Or we need a client migration from Service A to a Service B, which are designed for the same purpose, but with a completely different syntax?

Well - then things become confusing. To clean this up, let's consider to use something more structured. Like a shared domain dictionary or an enterprise data model.

Is an Enterprise Data Model the solution?

How about implementing an enterprise data model or a data dictionary? It consolidates the terminology to be used in all components. To do so, we meet with all stakeholders and define a company wide dictionary together. Updates of the data model are distributed. Changes to the dictionary are coordinated through a change process, such as a ticket system that fills a backlog. Releases are revised and reproducible.

We do this on all layers, the API, any kind of middleware and of course in the databases. 

This might result in such a design:

As a result, we would force all development teams to be fully compliant with the domain dictionary.

• All APIs, internal data models and DB structures must be approved by a senior architecture instance, like a review board or similar.
• If there is a change to the data model, all existing software needs to be adjusted within a certain time frame.
• Of course, if there is a 3rd party software included were we can't influence the data model, we need to define some exceptions from these rules.

When having a look at the concepts of Domain Driven Design, this is a pattern for relationships between contexts: A shared kernel... but in this case over all contexts!

As a result, we would introduce a dependency of all contexts on a single instance: The almighty domain dictionary. This undermines the agility and autonomy of the teams. 

→ What is necessary to keep a consolidated language, but also allow the teams to work independently and decoupled? Does Domain Driven Design (DDD) offer a solution for that?

Using a Domain Dictionary to feed a Sub Domains Ubiquitous Language during Strategic Domain Driven Design sessions

Wow, this is the winner of the most complex heading 2021... So what is the author trying to express?

DDD is not a new topic, but with today's scalable µService infrastructure it is easier to be implemented than ever. One of the key concepts of DDD is the ubiquitous language. This language is declared explicitly for a sub domain (not for the company's complete domain!) and clearly identifies the entities and their attributes.  One of the main goals of DDD is to transfer the natural terminology of the business language into the source code.

Doesn't that sound very similar to the corporate domain dictionary?

Indeed, but there is a difference - instead of a forcing authority, it is based on trust and good craftmanship:

The DDD procedures take care of a synchronization between the domain dictionary and the source code:

To have the business terminology in the algorithms, the interfaces, the data model, DDD defines the Strategic Domain Driven Design phase. In an agile environment, this is of course not an one-time-shot, but done continuously. 

There are different methods for Strategic DDD, like Event Storming or Domain Story Telling. Whatever method is used, a domain dictionary could be a very helpful input in this step. It keeps the ubiquitous languages of the different bounded contexts in sync with other sub domains.

As a result of this procedure, the terminology of all sub domains is now synchronized with the domain dictionary. Nevertheless, contexts are separated and can be connected according to the chosen DDD interaction pattern.

I think this is a valid compromise to control a global data model in the sense of an enterprise architecture and still offer the development teams an agile and flexible environment.