Tutorial Proposal: Using Domain Driven Design to Architect Microservices


Summary

One of the hardest parts of creating a microservices architecture is knowing where the boundaries are. Without proper boundaries and a good understanding of the necessary interaction patterns, your brand-new microservice-based system will fail. This tutorial shows how DDD can be used to find the boundaries and define useful service interactions.

I just posted this as a proposed tutorial at the O'Reilly Software Architecture conference next April in New York. I'm not holding my breath. My track record with O'Reilly conferences isn't great.

Abstract

One of the hardest parts of creating a microservices architecture is knowing where the boundaries are. Whether we're designing a new system or refactoring a monolithe that has become a "big ball of mud," microservides depend on getting the boundaries and interfaces right. Without proper boundaries and a good understanding of the necessary interaction patterns, your brand-new microservice-based system will just make the "big ball of mud" more complicated.

Microservices and Domain-Driven Design (DDD) are made for each other--they are both about boundaries. Using principles from DDD, we can understand the right places to split up the monolithe. DDD concepts like bounded contexts and ubiquitous language are concrete tools, with a large body of work behind them, that help designers find and enforce boundaries. Moreover, DDD principles help the architect understand how microservices can be as loosely coupled as possible so that problems in one part of the system don't spill over into the rest.

Part I of this tutorial is an introduction to microservices and the challenges of architecting a system using them. We will explore important microservices concepts such as isolation, team autonomy, planning for failure, and lightweight communication.

Part II covers the key parts of so-called strategic DDD such as domains, bounded contexts, and ubiquitous languages. We will apply them to microservices and explore how DDD's bounded contexts help with the design of key microservice requirements.

Part III focuses on microservice interfaces and shows how DDD context maps can be used to design them. Context maps not only document the interfaces, but classify them and give architects a tool for exploring possible problems with interface decisions. Good interface design is a key to building resilient microservice-based systems. DDD provides concrete tools for baking resiliency into the design

As part of the tutorial, students will participate in two hands-on exercises where they apply the principles they are learning. These exercises provide tools they can take back to their teams and use to get started on their own microservice designs.

Learning Objectives

At the end of this tutorial, students will be able to:

  • describe the key requirements for successful microservice design
  • understand DDD principles and apply them in finding the boundaries in a microservice architecture
  • explain a context map and show how context maps communicate interface issues in microservices

Instructor

Phillip J. Windley, Ph.D. has been a computer science professor at Brigham Young University for over 20 years where he teaches classes on distributed systems. Currently Phil is an Enterprise Architect in the Office of the CIO at BYU where he leads efforts across the university to apply domain-driven design (DDD) and microservice principles in architecting campus systems. Phil was the founder and CTO of iMall.com, an early ecommerce tools company and founder and CTO of Kynetx, an Internet of Things company that built the connected-car product Fuse.