BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Eric Evans Wants to Improve the Language of DDD

Eric Evans Wants to Improve the Language of DDD

Eric Evans, author of Domain-Driven Design, asked the audience during his keynote presentation at Explore DDD to actively engage in improving the language used when modeling and designing complex systems. Evans acknowledged that some of the fundamental terms used in DDD, such as Bounded Contexts, are often misunderstood. Other phrases, like "legacy software," create unproductive framing of a system, due to personal biases. While proposing several options for more clear language, he invited everyone to disagree with him. Only through an active community, with productive debate, will we meet the goal that DDD "should be a real, living body of thought."

Evans believes that now, 15 years after his book was published, it may be time to take a few steps back to the fundamentals, then consciously make new steps forward. One area of focus should be to address the confusion that results from the common alignment of bounded contexts, subdomains, and organizations. In many cases, one bounded context can align with an organization or team, and it can also align with a subdomain. However, large corporations are known for reorganizations, resulting in changes to business processes and responsibilities. When these re-orgs happen, the software does not change in the same way, so the stewardship of functionality becomes unclear. What may have previously been one organization's responsibility now requires two groups to collaborate to define requirements and priorties. Evans compared this to a three-legged race, where success requires the participants finding a balance between speed and coordination. An uncoordinated team will fall down, while a well-coordinated, but slow team won't win.

Acknowledging that much of the recent resurgence of DDD has come about because of the rise of microservices, he sees this as a great opportunity to start a productive conversation. Countering the opinion that some people just "jump on the microservices bandwagon," Evans believes, "Microservices is the battering ram knocking down barriers. Look at the opportunity among the chaos."

One common belief that is often repeated, "A microservice is a bounded context," is an oversimplification. Evans described four types of contexts within a microservices system:

  1. Inside a service
  2. The API of a service
  3. A cluster of services
  4. Interaction between services

As the context scope increases through this list, the type of thinking has to change from being narrow and focused, to a broad, architectural viewpoint. If every microservice was allowed to independently define a unique language and messages for communicating across the system, without architectural thinking, it would result in complete chaos.

Evans also wanted to reframe how people talk about legacy systems, and find ways to discuss them in more productive ways. Evans has often used the analogy of a garden. A newly planted garden has a great sense of order, but it's the late summer garden that has an "abundance of maturity," and that is where the value of a garden is found. Similarly, developers and architects should plant seeds with the goal of creating order, but also appreciate the chaotic abundance that exists from a mature system.

Rather than just a broad term, "legacy system," Evans proposed new ways to categorize and describe "mature contexts." Using DDD techniques, one should map out the contexts of a mature system, and draw the relationships between contexts. Fighting the instinct to always start from scratch can be helped by identifying the boring, routine responsibilities a mature context already handles, much as a mature garden is already productive. Evans pointed out that anti-corruption layers are bi-directional; they protect new code from the legacy system, and they also keep the legacy system from being affected by the new code.

When working with code that may be described as a Big Ball of Mud, it's important to remember that not all parts of a system will be well-designed. Once a system gets large enough, you can't get back to a tidy world. Instead, aim for the benefits that can be achieved with good boundaries, and isolating the tidier contexts.

Rate this Article

Adoption
Style

BT