When designing and building software systems, it’s important to have a clear understanding of the requirements and goals of the system. In school, we’re constantly reminded about how there are ways to build better, more efficient, or cleaner code. However, often times, the easiest way to make mistakes when it comes to software development are as a result of misunderstanding the purpose of what software should be doing, or by integrating our own biases as developers onto the systems we work on. In my experience, this “overhead complexity” compounds as soon as there are multiple stakeholders with different and sometimes competing requests for the same system. As a result, it’s crucial for software engineers to have a systematic approach to identify and prioritize these requirements. In this blog post, I want to discuss three approaches that can help solve the problem of how to build and model your system before writing code: Domain-Driven Design (DDD), Event Storming, and Message-Based System Design (MBDS).
Domain-Driven Design (DDD)
I only stumbled across the concepts of DDD within the past few years, and it was sort of by accident on YouTube: not through a course or through a job. DDD is essentially an approach to software design that emphasizes a strong focus on the problem domain: prioritizing understanding of the business logic and modeling that use case before adding all the technical complexity around it. It helps to identify the key elements and relationships of the domain and create a model that represents these elements and relationships. In the context of identifying requirements and competing requests, DDD can help to ensure that all stakeholders have a common understanding of the domain and the requirements for the system. One of the key benefits of using DDD is that it helps to break down complex problems into smaller, more manageable pieces. This makes it easier to identify and prioritize requirements, and to ensure that the requirements of different stakeholders are being met.
The core tenants of DDD are to identify bounded contexts within a system, and each of these sections of the system should be as cohesive and decoupled from other bounded contexts as possible. Thinking about the domain up front and involving diverse stakeholders with varied viewpoints can help identify these bounded contexts, and better isolate systems and code that would otherwise be coupled under the same development framework, causing technical debt and growing pains as a system continues to develop. In my (limited) experience, even adopting some small degree of this mentality can pay large dividends when working with complex systems: the more you can understand the actual problem, the more likely you can engineer an effective solution.
Event Storming
One key method used to facilitate DDD is Event Storming. Event storming is a workshop-style approach to software design that is used to identify and prioritize requirements, with the intent of identifying shortcomings in the domain understanding as soon as possible, rather than when some amount of development has already occurred. The goal of event storming is to create a visual representation of the events that occur in a system, and to identify the relationships between these events. In an event storming session, stakeholders come together to brainstorm and map out the events that occur in the system. This helps to identify the requirements for the system and to prioritize these requirements based on their importance to the stakeholders.
I have never participated in a full on event-storming session, but I have run smaller versions of event storming during project planning meetings and find it incredibly helpful in outlining a process and identifying gaps in knowledge. Due to the diverse group of stakeholders that can participate (not necessarily only technical people), it is highly likely that new ideas or understanding can be gained before any code is written.
Message-Based System Design (MBDS)
Lastly, I want to talk briefly about messages. MBDS is a design approach that focuses on defining the interactions between different elements in a system. The key elements in MBDS are messages, which are used to represent the interactions between different parts of the system. In MBDS, messages are defined using a specific format: actor, action verb in past tense with properties, on this system or another person. This format helps to clearly define the interactions between elements in the system, making it easier to identify competing requests and requirements.
For example, if “Application Admin” sends a message of “closed production work order” to “Manufacturing Shop Floor System”, with some minimal details (production Work Order ID, reason for close, etc), then we have a fairly clear idea of what information has to change hands and from which parties during this step of a process.
One of the benefits of MBDS is that it makes it easier to see the relationships between different elements in the system. By using a consistent format for messages, it becomes easier to identify where there may be conflicting requests or requirements.
Conclusion
In conclusion, when designing and building software systems, it’s important to have a clear understanding of the requirements and goals of the system.
By using approaches such as Domain-Driven Design (DDD), Event Storming, and Message-Based System Design (MBDS), software engineers can systematically identify and prioritize requirements and competing requests. These approaches can help ensure that all stakeholders have a common understanding of the domain, and that the requirements of different stakeholders are being met. By using these approaches, software engineers can build systems that meet the needs of all stakeholders, and deliver high-quality software that meets the needs of the users.
Leave a Reply