Applying Domain-driven Design Principles

In domain-driven design, a domain is a particular area of knowledge or activity. A model is an abstraction of important aspects of the domain that emerges over time, as the understanding of the domain changes. This model is then used to build the solution, for cross team communications

With monolithic systems, a single unified domain model exists for the entire application, and this works as long as the application remains fairly simple. Using a single unified model begins to fall apart when different parts of your application use seemingly common elements in different ways.

For example, the Catalog service in the Online Retail Store sample is focused on the items for sale, including descriptions, part numbers, product information, pictures, and so on. The Order service, by contrast, is focused on the invoice, with items represented minimally, perhaps only the part number, summary, and calculated price.

Bounded contexts allow a domain to be subdivided into independent subsystems. Each bounded context can then have its own models for domain concepts. Continuing the above example, both the Catalog and Order services can each have independent representations of items that best fit the needs of their service. This works great for the most part, but how do the two services share information with other services, given they have different representations for the same concept?

Context mapping, including the development and use of ubiquitous language, can help ensure that disparate teams working on individual services understand how the big picture should fit together. In the case of modeling a domain for a microservices application, it is important not to get down to the class or interface level when identifying the pieces that comprise the system. For the first pass, keep things at a high, coarse, level. Let individual teams working on the individual services work within their bounded contexts to expand on the details.

Ubiquitous language in Game On!

To give a concrete example of the importance of language, we’ll take a small detour into how Game On! was developed. The game was built to make it easier for developers to experiment with microservices concepts first-hand, combining the instant gratification of a quick hello world example with different ways to think about the more complex aspects of microservices architectures. It is a text-based adventure game, where developers add their own individual services (rooms) to extend the game.

The original metaphor for the game was akin to a hotel, with three basic elements: a Player service to deal with all things relating to game players; an initial Room service as placeholder for what developers would build, and an additional service we called the Concierge. The original purpose of the Concierge was to help facilitate the transition of a player from room to room.

What we discovered, after letting these three pieces of the system evolve over time, was that different people working on the game had different interpretations of what the Concierge was supposed to do. The Concierge did not work as a metaphor; it was too ambiguous. We replaced the Concierge with a new Map service. The Map is the ultimate source of truth for where a room is located in the game, and that is clearly understood from the name alone.