How We Used Domain-Driven Design to Pair Experts with Engineers and Build Network Automation Tools That Worked
Sometimes the biggest challenge in building great tools isn’t the tech itself—it’s getting the right people to work together in the right way. At Microsoft Ireland, we faced this head-on when tasked with creating tools to automate complex network operations. We had two groups of incredibly talented people: Cloud Network Engineers (CNEs), who knew networking inside out, and software engineers, who could build scalable systems. The problem? They didn’t speak the same language.
That’s where Domain-Driven Design (DDD) came in and helped us bridge the gap. By focusing on collaboration, shared understanding, and the power of a common language, we created a process where CNEs and software engineers could work together to solve real-world problems. The result was not just a set of tools, but a transformation in how our teams worked, communicated, and ultimately succeeded together.
In this post, I want to take you through our journey—what we learned, the obstacles we faced, and the magic that happened when experts and engineers came together to build something truly impactful.
The Messy Starting Point
When we started, network management was still largely manual. Configurations were written line by line, tailored to specific devices and protocols. Deployments often felt more like crossing your fingers and hoping for the best. This process wasn’t just tedious—it was risky and didn’t scale well as our infrastructure grew.
On one side of the room, we had the Cloud Network Engineers—seasoned professionals who understood the intricacies of every router, switch, and protocol like the back of their hands. On the other side, we had the software engineers—problem solvers ready to write code but struggling to make sense of the deeply technical and nuanced world of networking.
Neither group could succeed alone. The CNEs couldn’t automate their expertise, and the engineers couldn’t build what they didn’t fully understand. To make matters worse, the gap between them wasn’t just technical—it was cultural. Both groups were used to doing things their own way and struggled to see eye to eye.
Bridging the Gap with Domain-Driven Design
We turned to Domain-Driven Design (DDD) as a way to break down these barriers. DDD isn’t just about designing software—it’s about deeply understanding the problem space and working with domain experts to create solutions that truly meet their needs. It gave us the tools to align our teams, foster collaboration, and ultimately deliver results.
Step 1: Creating a Shared Language
One of the first things we did was establish what DDD calls a ubiquitous language—a shared vocabulary that everyone could use to describe the problem and the solution. This sounds simple, but it was a game-changer.
For example, CNEs would talk about “intent configurations,” meaning what they wanted the network to do, not how it should be done. Engineers, however, would fixate on technical implementation details. By agreeing on terms like “intent configuration,” “device template,” and “deployment queue,” we created a common ground. These terms became part of every conversation, diagram, and piece of code, ensuring everyone stayed on the same page.
It wasn’t always smooth sailing. Early on, we had a lot of back-and-forth about what certain terms meant and whether they accurately described the work. But over time, these discussions helped build trust and mutual understanding between the two groups.
Step 2: Bringing CNEs Into the Process
In many companies, domain experts like CNEs are treated as consultants—people you ask questions and then leave alone. We did the opposite. We made them core contributors to the design and development process. This meant having them in the room for brainstorming sessions, design reviews, and even sprint planning.
We used event storming workshops as a way to map out how the network worked and where automation could help. CNEs walked us through key events, like:
- Publishing a configuration
- Deploying that configuration to devices
- Handling failures or rollbacks
These workshops didn’t just give engineers a clearer picture of the domain—they gave CNEs a seat at the table. They saw their expertise being valued and directly influencing the design of the tools.
Building the Tools
With a shared language and a clear understanding of the problem, we started building. Here’s a closer look at some of the tools we created and how DDD guided their development.
The Intent Configuration System
One of our first goals was to simplify how CNEs created and deployed configurations. The old way involved writing device-specific scripts that were prone to human error. Using DDD, we designed a system where CNEs could express high-level intents like “create a VLAN for this application” or “enable this feature for this region.”
The system then translated these intents into low-level configurations tailored to each device. This removed a huge amount of manual effort and reduced errors significantly.
Automated Deployment Pipelines
Deployments were another area ripe for automation. Before, deployments involved manually copying configurations to devices, a process that could take hours or even days for large networks. We built pipelines that validated configurations, queued them for deployment, and monitored the results.
The key was involving CNEs in defining the rules and edge cases for these pipelines. They knew, for example, which configurations were most likely to fail and which ones required careful sequencing. By capturing this knowledge in the system, we made deployments faster and more reliable.
Real-Time Monitoring Dashboards
Finally, we created dashboards that gave CNEs visibility into the status of their deployments and the health of the network. These dashboards weren’t just for show—they became essential tools for troubleshooting and refining configurations. CNEs told us these tools saved them hours of guesswork and gave them confidence in the automation process.
The Challenges We Faced
Looking back, it’s easy to focus on the wins, but there were plenty of challenges along the way. Here are a few that stand out:
- Breaking Down Silos
Early on, there was some resistance from both sides. CNEs worried that automation might make their roles less relevant, while engineers struggled with the steep learning curve of networking concepts. Over time, we overcame this by emphasizing collaboration and celebrating shared wins. - Handling Complexity
Networking is full of edge cases, and it was tempting to oversimplify things in the name of speed. DDD helped us resist this urge by encouraging us to focus on bounded contexts—keeping each part of the system focused and manageable. - Iterating Quickly
We didn’t get everything right the first time. Some features missed the mark, but because we had rapid feedback loops in place, we were able to adjust quickly. Weekly demos became a cornerstone of our process, ensuring we stayed aligned.
The Results: A Win for Everyone
By the end of the project, we had a set of tools that transformed how network configurations and deployments were handled. Here are some of the outcomes we’re most proud of:
- 60% Time Savings: Automation reduced the time spent on manual configuration tasks dramatically.
- 80% Fewer Errors: Automated validation caught issues early, making deployments far more reliable.
- Better Collaboration: Perhaps most importantly, the process brought CNEs and engineers together in a way that hadn’t happened before. They didn’t just work together—they learned from each other.
What I Learned
Looking back on this experience, I’m struck by how much of our success came down to people and process, not just technology. Pairing domain experts with software engineers isn’t always easy, but when done right, it unlocks incredible potential.
If I had to boil it down to a few lessons, they would be:
- Talk Early, Talk Often: Don’t wait for the engineers to “figure it out” before involving domain experts. Start the conversation from day one.
- Build Trust: Make it clear that everyone’s expertise is valued. When people feel heard, they’re more willing to collaborate.
- Stay Flexible: No matter how much planning you do, some things won’t work. Be ready to adapt and iterate.
This project taught me that the best tools come from the intersection of expertise and engineering. By investing in collaboration and using DDD as our guide, we didn’t just build software—we built a team that could tackle any challenge.