7/2/2023 0 Comments Ddd bounded contextThe first is Service Internal, describing how a service works. He instead sees four kinds of contexts involving microservices. One problem he sees is that many believe that a microservice is a bounded context, but he thinks that’s an oversimplification. 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. He also describes and compares Generalist Context with Specialist Context.Įvans believes that microservices is the biggest opportunity, but also the biggest risk we have had for a long time. 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. Changing the basic assumptions of software often means that it ends up broken he therefore recommends against doing so. Too much misalignment can lead to a demand in transforming the existing context, but in Evans' experience, they often don’t transform so well. 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. 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.Ī Mature productive context is producing value, but probably built on concepts in the core domain that are outdated. 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. These two subdomains in the banking domain are also bounded contexts. He uses an example of a bank structured around cash accounts and credit cards. In an ideal world they coincide, but in reality they are often misaligned. One confusion that Evans sometimes notices in teams is differentiating between bounded contexts and subdomains. In a recently published presentation, he describes different kinds of bounded contexts, including some that involve microservices.Įvans, 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. None of the large software systems he has been involved in have been anywhere near that tidy. But a description of a system that looks so tidy is, for him, very suspicious. A canonical context has a refined model and an expressive ubiquitous language with unambiguous definitions. 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.
0 Comments
Leave a Reply. |