A bounded context is a defined part of software where particular terms, definitions and rules apply in a consistent way, Eric Evans explained in his keynote at DDD Europe earlier this year. A canonical context has a refined model and an expressive ubiquitous language with unambiguous definitions. But a description of a system that looks so tidy is, for him, very suspicious. None of the large software systems he has been involved in have been anywhere near that tidy. In a recently published presentation, he describes different kinds of bounded contexts, including some that involve microservices.
Evans, a thought leader in DDD and author of the seminal book Domain-Driven Design, notes that the bounded context as a concept has drawn increasing interest from the community over the years, but is still an area where there is more to be done. One confusion that Evans sometimes notices in teams is differentiating between bounded contexts and subdomains. In an ideal world they coincide, but in reality they are often misaligned. He uses an example of a bank structured around cash accounts and credit cards. These two subdomains in the banking domain are also bounded contexts. After reorganising the business around business accounts and personal accounts, there are now two other subdomains, but the bounded contexts stay the same, which means they are now misaligned with the new subdomains. This often results in two teams having to work in the same bounded contexts with an increasing risk of ending up with a big ball of mud.
A Mature productive context is producing value, but probably built on concepts in the core domain that are outdated. An important question to ask is how misaligned its core domain is, when compared to the current view of the core domain, and how much this is constraining the evolvement of the business. Too much misalignment can lead to a demand in transforming the existing context, but in Evans' experience, they often don’t transform so well. Changing the basic assumptions of software often means that it ends up broken; he therefore recommends against doing so.
Other types of contexts Evans describes include Quaint context, an old context which still does useful work, but maybe is implemented using old fashioned technology and not aligned with the current vision of the domain, and Generic subdomain context together with Generic Off the Shelf (OTS) context, which address an important generic subdomain in a conventional way that other contexts must conform to. He also describes and compares Generalist Context with Specialist Context.
Evans believes that microservices is the biggest opportunity, but also the biggest risk we have had for a long time. What we should be most interested in is the capabilities they give us to fulfil the needs of the business we are working with, but he also warns against the bandwagon effect. One problem he sees is that many believe that a microservice is a bounded context, but he thinks that’s an oversimplification. He instead sees four kinds of contexts involving microservices.
The first is Service Internal, describing how a service works. For Evans, this is the type people think about when they say that a microservice is a bounded context. Here a service is isolated from other services and handled by an autonomous team. This fits his definition of a bounded context, but he notes that it’s not enough. Using only this type, we would end up with services that don’t know how to talk to each other.
The second is API of Service, describing communication with other services. One challenge here is how teams design and adapt to different APIs. Data-flow direction could determine development dependency with consumers always conforming to an upstream data flow, but Evans think there are alternatives. Highly influential groups may create an API that other groups must conform to, for example with authorities, where you commonly must adapt to their APIs irrespective of the direction data is flowing.
The third is Cluster of codesigned services. When several services are designed to work with each other to accomplish something, they together form a bounded context. Evans notes that the internals of the individual services can be quite different with models different from the model used in the API.
The final type is Interchange Context. Evans points out that the interaction between services also must be modelled. The model in this context describe the messages and definitions to use when services interact with other services. He notes that there are no services in this context; it’s all about messages, schemas and protocols.
Exposed Legacy Asset can be useful when we want a legacy system to participate in a microservices environment. One way is to create an interface that looks like a microservice and interacts with other microservices, but internally interacts with a legacy system. This keeps us from corrupting the new microservices built, but it also keeps us from having to change the legacy system; they are often fragile and can be corrupted and even turned into a big ball of mud.
Evans concludes by trying to define what DDD really is. A challenge is how tightly should DDD be defined. A definition should share a common vision and language, but should also be flexible to allow for innovation and improvement. The community is important, but it must be an honest community open to the possibility of being wrong when the result isn't as expected. He also thinks we should try to clarify the limits of applicability of DDD; all software projects should not be done with DDD. He summarizes by defining DDD as a set of guiding principles: focus on the core domain, explore models in a creative collaboration, and speak a ubiquitous language within a bounded context. His final words were:
Let's practice DDD together, shake it up and renew.