Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

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:

Inside a service

The API of a service

A cluster of services

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.