Basic Notions of Domain-Driven Design

Most of the effort in domain-driven design goes into the development of the ubiquitous language and identifying bounded contexts. However, the design work is not done, once you have the contexts identified. In practice, DDD recognizes three major types of the domains, and related context types: core, supporting, and generic. You can see an example of this on [Link to Come]. It is important to identify the correct type of the domain, in order to make decisions about the level and type of effort that should be applied to its implementation.

Figure 7-2. Core, Supporting, and Generic domain types.

Core Domain is the distinctive part of a model, central to the user’s goals, that differentiates the application and makes it valuable.

For instance, in [Link to Come], representing possible domains of an online flight reservation system, we could decide that Product Presentment, the user interface that allows customers to find and select desired flights is the core domain. It is essential to customer’s ultimate goal of finding a suitable flight and the overall functionality of the system . Its unique implementation is what differentiates a flight reservation system from, say apparel online store - the online store’s product presentment would likely be significantly different from that of a flight reservation system. Therefore Product Presentment domain is the core domain of the system.

We will further need to identify key “supporting domains” of the system. These are the domains that can materially differentiate us from the competition, in the same space, if we get them right. A well-known example of such key supporting domain comes from the early days of amazon.com The care and level of innovation that Amazon.com poured into the checkout experience on their website, seemingly a commodity functionality, was quite astounding for the outside observers. By inventing the one-click purchasing and fine-tuning smallest details of the experience to maximize conversion and completion rates, Amazon.com put a lot of care in this subdomain, even if it wasn’t a core domain from the first sight.

In our case, we could identify “fulfillment” as a key supporting sub-domain.

And lastly, any large enough system will have generic sub-domains that provide undifferentiated functionality. It is important to identify them, but it may not be economically advisable to pour a lot of in-house effort in implementing them. It may be better to integrate an off-the-shelf solution, instead. It is important to note that even for the same capabilities the categorization as a generic domain will differ from one business application to another. For many, checkout system would have been a generic domain, but for amazon.com it was essential. Similarly, in our case we have marked “Identity and Access Management” as a generic domain. That made sense for a run-of-the-mill online travel reservation system. However, if you are a large financial institution, Identity & Access management is your front door to fend off enormous amount of attacks and fraud, so your perspective on how “generic” of a solution you can afford, will very likely be different.

Armed with the understanding of key types of domains, let’s talk about the key relationship types we observe between domains.

Context Mapping

We’ve already mentioned that in Domain-Driven Design, we do not attempt to describe a complex system with a single domain model. Rather, we design multiple independent models that co-exist in the system. These sub-domains typically communicate with each other using pre-defined interfaces. The representation of various domains in a larger system and the way they collaborate with each other is called a Context Map. Consequently, the act of identifying and describing said collaborations is known as Context Mapping.

Figure 7-3. Context Mapping

Domain-Driven design identifies several major types of collaboration interactions when mapping bounded contexts.The most basic type is known as "Shared Kernel“. It occurs when two domains are developed largely independently and almost by accident they end-up overlapping on some sub-set of each-other’s domains. Two parties may agree to collaborate on this shared kernel, which may also include shared code and data-model, in addition to the domain description.

Figure 7-4. Shared Kernel

While tempting on the surface of things (after all, desire for collaboration is one of the most human of instincts), shared kernel is a problematic pattern. Especially so when it’s used for microservice architecture. By definition Shared kernel immediately requires high degree of coordination between two independent teams to even jump-start the relationship, and keeps requiring coordination for any further modifications. Sprinkling your microservice architecture with shared kernels will introduce many points of tight coordination.

As you should remember from our earlier discussions, that level of tight coupling and coordination would destroy the main purpose of a microservice architecture—to minimize coordination costs in order to achieve speed and safety, in harmony, at scale. Shared Kernels are problematic in Domain-Driven Design, in general, but should be avoided even more, when DDD is used in a Microservice Architecture.

Alternatively, two bounded contexts can engage in what DDD calls an Upstream–Downstream kind of relationship. In this type of relationship, Upstream acts as the provider of some capability, and the downstream is the consumer of said capability. Since domain definitions and implementations do not overlap this type of relationship is more loosely coupled than Shared Kernel.

Figure 7-5. Upstream-Downstream Relationship

Depending on the type of coordination and coupling, Upstream-Downstream mapping can be introduced in several forms:

Customer-Supplier

In customer-supplier scenario upstream (Supplier) provides functionality to the downstream (Customer). As long as provided functionality is valuable, everybody is happy, however Upstream carries the overhead of backwards compatibility. When they modify their service they need to make sure that they do not break anything for the customer. More dramatically, downstream (Customer) carries the risk of Upstream intentionally or unintentionally breaking something for it, or ignoring customer’s future needs.

Conformist

An extreme case of the risks for Customer-Supplier relationship is the Conformist relationship. It’s a variation on Upstream-Downstream, when Upstream explicitly does not or cannot care about the needs of its downstream. It’s a “use-it-at-your-own-risk” kind of relationship. Upstream provides some valuable capability that downstream is interested in using, but given that upstream will not cater to its needs, downstream needs to constantly conform to the changes in the upstream.

Conformist relationships often occur in large organizations and systems when a much larger sub-system is used by a smaller one. Imagine developing a new, innovative fintech startup inside a large bank and needing to use, say, enterprise payment system or enterprise credit bureau reporting system. Such large enterprise systems are likely not going to give time of the day to some small, new initiative but you also cannot just re-implement a whole payment system on your own. You will either have to become a Conformist, or another viable solution may be to Separate Ways. The latter doesn’t always mean that you will implement similar functionality yourself. As we already mentioned, something like a payments system is complex enough that no startup should implement it as a side job of another goal, but you might be able go outside the confines of your enterprise and use a commercially-available payments vendor instead, if your company allows it.

In addition to becoming a Conformist or going Separate Ways, downstream has couple more DDD-sanctioned ways of protecting itself from the negligence of its upstream: Anti-Corruption Layer and using upstreams that provide Open Host interfaces.

Anti-Corruption Layer

In this scenario, downstream creates a translation layer called Anti-Corruption Layer between its and the upstream’s Ubiquitous Languages, to guard itself from future breaking changes in the upstreams’s interface. Creation of an ACL is an effective, sometimes necessary, measure of protection, but teams should keep in mind that long-term it can be quite expensive, for the downstream, to maintain it.

Figure 7-6. Anti-Corruption Layer

Open Host Service

When upstream knows that multiple downstreams may be using its capabilities, instead of trying to coordinate needs of its many current and future consumers, it should instead define and publish a standard interface, which all consumers will need to adopt. Such upstreams are known as Open Host services, in DDD. By providing an open, easy protocol for all authorized parties to integrate with, and maintaining said protocol’s backwards-compatibility or providing clear and safe versioning for it, the Open Host can scale its operations without much drama. Practically all public services (APIs) use this approach. For example, when you are using APIs of a public cloud provider (AWS, Google, Azure etc.), they usually don’t know or cater to you specifically, they have millions of customers, but they are able to provide and evolve a useful service by operating as an Open Host.

Figure 7-7. Open Host Service

In addition to relation types between domains, context mappings can also differentiate based on the integration interfaces used between bounded contexts.

Synchronous vs. Asynchronous Relationships

Integration interfaces between bounded contexts can be synchronous or asynchronous, as shown on [Link to Come]. None of the integration patterns fundamentally assume one or the other style.

Figure 7-8. Synchronous and Asynchronous Integrations

Common patterns for synchronous integrations between contexts are RESTful APIs deployed over HTTP, gRPC services using binary formats such as protobuf, and more recently: services using GraphQL interfaces.

On the asynchronous side, publish-subscribe type of interactions lead the way. In this interaction pattern, upstream can generate events, and downstream services have workers able and interested in processing those, as depicted in the above diagram.

Publish/Subscribe interactions are more complex to implement and debug, but they can provide superior level of scalability, resilience and flexibility, in that: multiple receivers, even if implemented with heterogenous tech stack, can subscribe to the same events using a uniform approach and implementation.

A good example of such interactions, in the microservices world, can be a loan origination system. When a customer applies for a bank loan, the acquisitions system may publish an event and multiple other domains can consume it, each doing their part of the job, ideally in parallel. Such process could be described as:

• Message sent (Acquisitions system): loan application submitted

• Received by fraud-check domain/bounded context

• Received by credit-check and approval domain/bounded context

• Received by Anti-Money-Laundering-check domain/bounded context

• Received by OFAC-check domain/bounded context

These days, a lot of pub/sub interactions between microservices are brokered by various event streaming systems, most popular among which are Kafka, Rabbit MQ, and cloud-provided systems such as AWS SQS or Kinesis.

When implementing your asynchronous interactions, it is easiest to just use the native protocol of the event streaming solution, e.g. have publisher and subscribers talk “directly” to Kafka. However, if you don’t want your entire system to become a “hostage” of today’s choice of the implementation for message-streaming, you may decide to abstract your services away from it. Sure, Kafka is an amazing piece of open-source software, with huge fanbase, but it didn’t even exist several years ago. What happens when next cool system emerges? Will you want to rewrite every single microservice in your architecture just so you can replace Kafka with Even-Cooler-System? Depending on what your answer to this question is, you have a choice. There is a W3C standard called WebSub that allows you model pub/sub interactions, using non-vendor-specific, HTTP-based open protocol:

Figure 7-9. WebSub Interaction Flow Diagram

WebSub allows abstracting Pub/Sub model away from specific, non-web protocols used by concrete message broker systems and projecting the interactions onto the standard HTTP layer, with main benefit being ubiquitous familiarity with the protocol, built-in caching and internet-level scalability features.

To wrap up the discussion of Domain-Driven Design’s key concepts, we should explore the concept of an Aggregate. We discuss it in the next section.

A DDD Aggregate

An Aggregate, in DDD, is a collection of related domain objects that can be viewed as a single unit, by external consumers. Those external consumers only reference a single entity in the aggregate, and that entity is known as “aggregate root”, in DDD. Aggregates allow domains to hide internal complexities of a domain, and exposing only information and capabilities (interface) that are “interesting” to an external consumer. For instance, in the upstream/downstream mappings that we discussed earlier, downstream does not have to, and typically will not want to know about every single domain object within the upstream. Instead, it will view the upstream as an aggregate, or a collection of aggregates.

We will see the notion of an aggregate resurfice, later in this chapter when we discuss Event Storming - a powerful methodology that can greatly streamline the process of Domain-Driven Analyze and turn it into a much faster, fun exercise. Without further ado, let’s explore Event Storming in the next section.

Event-Storming Process

The beauty of Event-Storming is in its ingenious simplicity. All you need to hold a session of Event Storming is a very long wall (longer the better), a bunch of supplies, mostly stickies and sharpies, 4-5 hours of time from well-represented members of your team, meaning: you want engineers, business stakeholders, product, and design people to all show up.

The process starts by purchasing the supplies. To make things easier Irakli has created an Amazon shopping-list² he uses for Event Storming sessions. It is comprised of:

1. Large number of stickies of different colors. Most importantly: orange, blue and several other colors, for various object types. You need A LOT of those. Local stores never had enough, which is why I got in the habit of buying online.

2. A roll of 1/2-inch White Artist Tape

3. A long roll of paper (e.g. IKEA Mala Drawing Paper) that we are going to hang on the wall using the artist tape. Go ahead and create multiple “lanes”.

4. At least as many Sharpies as the number of session participants. Everybody needs to have their own!

5. Did we already mention a long, unobstructed wall that we can tape the roll of paper to?

Figure 7-10. Required Supplies For An Event Storming Session

Once we have the supplies, a large room with a wide wall and all required people we (the facilitator) ask everybody to grab a bunch of orange stickies, and a personal Sharpie. Then we give them a simple assignment: to write the key events of the domain, being analyzed, as orange post-it notes (one event per one note), expressed in a verb at past tense, and place notes along a timeline on the roll of paper we had taped to the wall to create a “lane” of time, as shown on [Link to Come].

Figure 7-11. An Event Timeline With Post-It Notes

Participants should not obsess about the exact sequence of events and at this stage there should be no coordination of events among participants. The only thing they are asked is to individually think of as many events as possible and put the events they think occur earlier in the time, to the left, while putting the ones that occur later, more to the right. It is not their job to weed-out duplicates. At least - not yet. This phase of the assignment usually takes 30 minutes to an hour, depending on the size of the problem and the number of participants. Usually, you want to see at least 100 event post-its generated before you can call a success.

In the second phase of the exercise, the group looks at the resulting set of notes on the wall, and with the help of the facilitator, starts arranging them into a more coherent timeline, identifying and removing duplicates. Given enough time, it is very helpful for the participants to start creating a “storyline” walking the events in an order that makes something like a “user journey”. In this phase team may have some questions or confusions, we don’t try to solve those, rather capture them as “hotspots” - differently colored post-it notes (typically purple) that have the questions on them. Hotspots will need to be answered offline, in follow-ups. This phase can likewise take 30-60m.

In the third stage, we create what in Event Storming is known as a “reverse narrative”. Basically, walking the timeline backwards - from the end to the start and identifying “commands” - things that caused the events. We use post-its of a different color (typically: blue) for the commands. At this stage your storyboard may look something like [Link to Come].

Figure 7-12. Introducing Commands To Event Storming Timeline

Be aware that a lot of commands will have one-to-one relationship with an event. It will feel redundant, like the same thing worded in past vs. present. Indeed, if you look at the diagram above, the first two commands are like that. It often confuses people new to Event Storming. Just ignore it! We don’t pass judgement during event storming, and while some commands may be 1:1 with events, some will not be. For example, “Submit payment authorization” command triggers a whole bunch of events. Just capture what you know/think happens in real life and don’t worry about making things “pretty” or “neat”. The real world you are modeling is also usually messy.

In the next phase, we acknowledge that commands do not produce events directly. Rather, special type of domain entities accept commands and produce events. In Event Storming, these entities are called Aggregates (yes, the name is inspired by the similar notion in Domain-Driven Design). What we do in this stage, is re-arrange our commands and events, breaking the timeline when needed, such that the commands that go to the same aggregate are grouped around that aggregate and events “fired” by that aggregate are also moved to it. You can see an example of this stage of Event Storming on [Link to Come].

Figure 7-13. Aggregates On An Event Storming Timeline

This phase of the exercise can take 15-25 minutes. Once we are done with it, you should discover that our wall now looks less like a timeline of events and more like a cluster of events and commands grouped around “aggregates”.

Guess what? These clusters are the bounded contexts we were looking for.

The only thing left is to classify various contexts by the level of their priority (similar to “root”, “supportive”, and “generic” in DDD). To do it, we create a matrix of bounded context/subdomains and rank them across two properties: difficulty, and competitive edge. In each category we put T-shirt sizes: S, M, or L to rank accordingly. In the end, the decision-making for where to invest effort goes based on the following guideline:

1. Large competitive advantage / Large effort - these are the contexts to design and implement in-house and spend most time on.

2. Small advantage / Large effort - buy!

3. Small advantage / Small effort - great assignments to trainees.

4. Other combinations are a coin-toss and require judgement call.

This last phase, the “competitive analysis” is not part of Brandolini’s original Event Storming process, and was proposed by Greg Young for prioritizing domains in DDD, in general. We find it to be a useful and fun exercise, when taken with the adequate levels of sense of humor.

Entire process is very interactive, requires involvement of all participants and usually ends up being fun. It also requires experienced facilitator to keep things moving smoothly. The good news is: being a good facilitator doesn’t take the same effort as becoming a rocket scientist (or DDD expert). After reading this book and facilitating some mock sessions for practice, you can be a world-class Event Storming facilitator, easily!

As a facilitator, it is a good idea to watch time and have a plan for your session. For a 4-hour session rough allocation of time would look like:

1. Phase 1: (~30mins) Discover Domain Events

2. Phase 2: (~45mins) Enforce the Timeline

3. Phase 3 (~60mins): Reverse Narrative + Command Identification

4. Phase 5 (~30min): Identify Aggregates/Bounded Contexts

5. Phase 6 (~15min): Competitive Analysis

And if you noticed that these times do not add up to 4 hours, keep in mind that you will want to give people some breaks in the middle, as well as leave yourself time to prepare the space and provide guidance in the beginning - prepare the space etc.

The Universal Sizing Formula

To achieve reasonable sizing of microservices you should:

• Start with just a few microservices. Possibly using bounded contexts.

• Keep splitting, as your application and services grow, being guided by the needs of Coordination Avoidance.

• Trajectory of being on the right course for decreasing coordination is vastly more important than the current state of how “perfectly” you got service sizing.