Domain-Driven Design: a SoftwareMill way

Modern software development demands not only a solid understanding of technology but also a comprehensive grasp of the business driving the software. This includes knowledge of the operational domain and organizational structure. Fortunately, the software development industry has developed various techniques that help with this task.

A common umbrella encompassing well-known patterns and tools is Domain-Driven Design (DDD). In this article, serving as an introduction to the series on "Domain-Driven Design: a SoftwareMill way" I will provide a brief overview of what this project will be about. Therefore, this is not an exhaustive article about this project or DDD in general, but rather a sneak peek into what you can expect on our tech blog shortly.

Check all the articles from the series:

• Domain Driven Design: A SoftwareMill Way
• Mastering Chaos with Big Picture Event Storming
• Finding the Gaps with Big Picture Event Storming
• Event Storming from a non-technical domain expert perspective
• Big Picture Event Storming: Simple Workshops, Big Benefits for Your Business
• Managing complexity and uncertainty in Software Development: know when to press pause
• Remote Event Storming challenges from a facilitator's perspective

The Why

At SoftwareMill, we specialize in assisting businesses of various sizes with their digital transformation journeys. Our portfolio contains a wide array of projects, each addressing complex business domains across numerous industries. Our expertise includes end-to-end projects that involve analyzing and gathering requirements and crafting and implementing solutions, followed by ongoing maintenance and support.

However, most of these projects are protected by non-disclosure agreements (NDAs), which limits our ability to share specifics publicly. Nevertheless, due to our commitment to spreading knowledge and experience, we were exploring ways to showcase our way of working with clients during the software development journey. And this is how the idea of this project was born.

Our goal here is to spread the knowledge and our experience with Domain-Driven Design together with multiple complementary tools and techniques we use regularly on clients’ projects. By showcasing it, we aim to share our experience and knowledge with the community while also presenting our unique approach to certain aspects of Domain-Driven Design, derived from SoftwareMill's experience in remote work.

The What

Understanding that this is quite a big thing, we have decided to divide our project into several parts. In this phase, we aim to choose an example from the real-life domain and break it down into its fundamental elements to comprehend how this specific business aspect functions.

So, how do we plan to achieve this? By employing the same methods we use with our real-life clients.

When clients seek our help, we initially need help to fully grasp the needs. We also may not have a clear understanding of how their business operates, how it generates revenue, and other key aspects that make this business successful. To develop reliable, well-crafted solutions, gaining a deep and thorough understanding of these elements is essential.

Thus, we usually start with a series of workshops aimed at comprehending the client's business, needs, and requirements. Interestingly, these sessions sometimes even help the client better understand their own business or find potential improvements in the workshopped process.

We employ various techniques in this phase, but one of the most effective is the (Big Picture) Event Storming workshop. This approach is particularly useful for exploring business domains, processes, and actors involved there.

Event Storming workshop is the technique that we want to present to you in the first phase of this project, which has two goals. The first is to define the criteria and select the domain we will tackle throughout this project. The second goal is to organize and conduct the Big Picture Event Storming session, which will aid us in gaining a deeper understanding of the chosen domain.

What is Domain-Driven Design?

While the primary goal of this article isn't to thoroughly explain DDD, having a basic understanding of what this term stands for is crucial for a better grasp of this project. Thus, I will shortly explain this methodology.

In DDD, the structure, logic, and language of the code match the business domain which is typically expressed by so-called ubiquitous language, making the software more relevant, intuitive, and adaptable to business changes. This methodology is particularly valuable for complex domains where business concepts and rules play a crucial role.

Domain-Driven Design places a strong emphasis on the development of a domain model, which serves as a conceptual framework that captures the nuances, operations, and rules of the business domain. This model is continuously refined through collaboration between developers and domain experts, ensuring it remains a faithful representation of the domain's complexities.

The domain model becomes the foundation of the system, guiding the design and implementation of features and ensuring the software can evolve in response to changes within the business environment.

If you’re in an engineering role and keen to explore more about DDD principles, there are several excellent books and articles out there. One that I particularly recommend for beginners is “Learning Domain-Driven Design” written by Vlad Khononov, which we recently covered in our last edition of the reading club in SoftwareMill. If you want more, I also recommend "Domain-Driven Design", commonly known as “Blue Book”, written by Eric Evans.

On the other hand, if you're not from a technical background but are interested in understanding more about DDD, I suggest reading my recent article. It explains the core concept of DDD, its benefits to an organization, and the business value it brings, all without delving too deeply into complex technical jargon.

Choosing a complex business domain

We dedicated some time to finding the appropriate domain. On the one hand, we wanted to avoid a problem that was too trivial, as this would reduce our task to mere basic CRUD (Create, Read, Update, Delete) operations. On the other hand, choosing a too complex domain could undermine our ability to effectively showcase it, as quite a lot of effort would be required to explain its intricacies.

An additional consideration was our access to domain knowledge; we couldn't opt for a domain completely unfamiliar to us or where we lacked contacts with expertise, as executing such a project would be extremely challenging, if not impossible. Moreover, we had to be mindful of all the NDAs in place.

Finally, we decided to focus on a process that is well-established within our company and for which we have great domain expertise: the device/equipment management process. This process comes into play whenever a new device is needed for our coworkers, whether it's for a new joiner requiring a computer, or due to a device being damaged or simply not being performant enough for our day-to-day software development needs.

Our administration team plays a key role in handling this process. They manage the inventory of available devices, including spare and emergency ones, and they also determine when to order new devices or decommission existing ones.

At first glance, this might not seem overly complex. However, we discovered some nuances in the process, which we aim to highlight in this blog post series. We were satisfied with this choice because the process is straightforward enough to demonstrate yet goes beyond basic CRUD operations. Moreover, everyone more or less understands how the process works, at least at a high level, making it quite easy to grasp the ubiquitous language we have developed.

The Team

After selecting the business process that we wanted to tackle, it was the right time to delve into this domain. As developers, our understanding of the inventory process was limited to a user's perspective (yes, we need computers and other devices) and was quite superficial. Therefore, we required the help of experts to conduct Big Picture Event Storming sessions for a deeper understanding of this domain.

Choosing the right participants for Event Storming is crucial to the success of this workshop. Conducting it without the appropriate experts could lead to wasted time. And who are these “appropriate people”? They are usually individuals who can answer the questions of developers or modelers. These could be those involved in the process as executors, users, supervisors, or designers.

It's also beneficial to include people with diverse perspectives on the domain being explored. More diversity equals better outcomes, but too many participants can also lead to chaos.

In our case, selecting the right participants was relatively straightforward. We invited our dear colleagues from the administration department, who are both users and designers of the device management processes at SoftwareMill. Please meet Małgosia and Joanna:

So, we had the people with the answers. Next, we needed ones who could ask the right questions. This role was aptly filled by my colleague Michał and myself:

Every Event Storming session requires one person who ensures that the session’s objectives are achieved. This person is responsible for maintaining participant engagement and energy. Our sessions were expertly facilitated by Mateusz, who excelled in managing the chaos and steering the group dynamics very effectively.

Event Storming workshop planning

Before launching the session, we took a few steps to enhance its chances of success. First, we introduced our administration experts to the Event Storming workshop format. We explained what they could expect during the session, how it would be conducted, and how to prepare for that (setting up a Miro account, ensuring a good headphone setup, etc.). This wasn't an exhaustive rundown of Event Storming but rather a few key teasers. Typically, the facilitator elaborates on the details during the workshop.

It's worth mentioning that the sessions were conducted online using Miro. Most resources on Event Storming, including its creator Alberto Brandolini, suggest conducting sessions in a room with real sticky notes and a vast, blank sheet of paper for unlimited modeling space on the wall (this approach was changed during the pandemic). While I agree that being in the same room and witnessing each other's emotions is advantageous for such workshops, at SoftwareMill, we are strongly experienced in remote work.

Being a fully remote company since starting, an online session was our natural first choice. Our extensive experience with remote tools significantly aids us in mitigating the challenges of remote workshops. This approach is how we typically work with our clients, and we wanted to showcase this aspect.

Then, we scheduled the first session. We were aware that the meeting shouldn't be too long to maintain everyone's focus. Therefore, we allocated a 5-hour timeslot, anticipating a break after a specific workshop part and continuing in another session. This is a benefit of remote Event Storming: it's much easier to divide the workshop into several shorter meetings since gathering all participants in one location isn't necessary. This approach helps in keeping the participants focused and in a good mood.

Finally, Mateusz set up the Miro board. He invited all participants to the Google Meet meeting, and we were all eagerly waiting for the first Event Storming session.

Outro

I'm sure you're equally eager to learn about how this session unfolded. This will be detailed in upcoming articles, where we will showcase how the session proceeded, focusing on explaining all the workshop phases, identifying the advantages and challenges of remote sessions, and how we addressed them.

We also plan to conduct an interview with our domain experts to gather their impressions of the workshop. Stay tuned!

Check all the articles from the series:

• Domain Driven Design: A SoftwareMill Way
• Mastering Chaos with Big Picture Event Storming
• Finding the Gaps with Big Picture Event Storming
• Event Storming from a non-technical domain expert perspective
• Big Picture Event Storming: Simple Workshops, Big Benefits for Your Business
• Managing complexity and uncertainty in Software Development: know when to press pause
• Remote Event Storming challenges from a facilitator's perspective