The Cynefin framework with Domain-driven Design

I first met the term ‘Cynefin’ when learning Domain-driven Design. I have seen multiple mentions of this framework, but not all of them were related to software development, especially DDD. The thing here is that the Cynefin framework is not directly related to the software industry. It is more than that. In simple terms, the Cynefin framework, developed by Dave Snowden back in 1999, is a decision-making and sense-making tool designed to help leaders and organizations deal with complex problems and make better decisions.

I know you may have tried to learn it before this article, and because of its complexity and complex explanations, you may fail. This article aims to try to explain it as simply as possible.

If you learn DDD, you may notice that understanding the domain is important and trying to understand how complex the domain is really complex.

Cynefin framework and domain-driven design(DDD) address complexity, deal with complex systems, and aim to provide frameworks for managing uncertainty. Cynefin categorizes problems to determine how to address them. On the other hand, DDD focuses on managing complexity in business domains by modeling them effectively.

Using Cynefin, we can identify which domain(s) in a system are Complex or Complicated, influencing how DDD might be applied.

Cynefin’s primary purpose is to guide decision-makers in understanding the context of a situation and applying appropriate strategies.

So far, so good. Now, we have some basic understanding of the Cynefin framework, and it is time to dive into the five realms of the framework.

using System;
using System.Text.RegularExpressions;

class Program
{
    static void Main()
    {
        Console.WriteLine("Enter an email address:");
        string email = Console.ReadLine();

        if (IsValidEmail(email))
        {
            Console.WriteLine("The email is valid.");
        }
        else
        {
            Console.WriteLine("The email is invalid.");
        }
    }

    static bool IsValidEmail(string email)
    {
        if (string.IsNullOrWhiteSpace(email))
        {
            return false;
        }

        // Simple email validation regex
        string emailPattern = @"^[^@\s]+@[^@\s]+\.[^@\s]+$";
        return Regex.IsMatch(email, emailPattern);
    }
}

A real-world example of a clear-domain problem involving a car wash where the water supply runs out might look like this:

1. Sense

Recognize the problem: The car wash system detects that the water supply has been depleted (e.g., through a water level sensor or manual observation). The cause is obvious and easily identifiable: there is no water left to continue operations.

Example

The water tank for the car wash is empty, and the system cannot proceed with washing cars.

2. Categorize

Match the situation to a known category: Categorize the problem as "resource depletion."

Determine the standard operating procedure (SOP) for refilling the water tank. This is a routine task with established steps.

Example Categorization

Check the water tank level. Confirm it needs refilling. Identify the nearest water source or supplier for replenishment.

3. Respond

Apply the known solution: Follow the established procedure to resolve the problem. Notify the operator to refill the tank or automatically trigger the water refilling mechanism if the system is automated.

Example Response: Refill the water tank from the designated source. Ensure the tank is full. Resume car wash operations once the water is replenished.

The next domain is the Complicated domain. The main approach here is “sense-analyze-respond”. A complicated domain represents situations where problems are more challenging than in the Clear domain, but they are still solvable with expertise and analysis. The cause-and-effect relationships exist, but they are not immediately obvious and require deeper investigation.