What we discovered with DDD and Bounded Contexts
Introduction
Hi, I'm Eddie Fitzpatrick, Director of Product Architecture at Workhuman. I’ve been with Workhuman for more than 18 years, during which time our team has guided the company’s technology strategy through multiple shifts—from server virtualisation to platform engineering, public cloud, and most recently to AI. Working closely with our Product partners, we help shape the features and innovations that have established Workhuman as the leader in the Recognition market. Outside of work, I’m an avid cyclist, runner, and swimmer, and I’ve found that consistently pursuing and achieving new goals builds habits that carry over into every part of life.
As architects in a highly successful software company with a 25-year history, we continuously balance innovation, long-term strategy, engineering, and product portfolio needs. In this article, I’d like to share one example: a project where we began with a clear strategic business goal— to reduce the cognitive load and risk for Engineers working with our systems. We identified a modern best practice technique, made multiple attempts to apply it to our codebase and ultimately, produced a crucial reference for decision-making and uncovered a capability that has brought many benefits to the technology organisation.
Overview
Domain-Driven Design (DDD) offers a powerful approach to managing complexity in large software systems. At its core are bounded contexts—distinct models with clear boundaries where specific business logic and language apply. Within each bounded context, teams develop a ubiquitous language, a shared vocabulary that unifies technical and business stakeholders around a common understanding of the domain.
For organisations with monolithic architectures, DDD provides a lens through which to view complexity and chart a path toward clearer boundaries and better alignment. This is the story of our journey applying these principles to a complex enterprise system.
The Problem: Large codebase, Shared Database and Tight Coupling
Our starting point was a monolithic codebase accumulated over 25 years. This large system housed everything from authentication and localisation to user transactions, profile data, ecommerce store functionality, order management, and financial processes. Features had been added incrementally, creating a dense web of interdependencies.
The organisational impact was significant. Teams worked across a mix of loosely-defined domains where terminology was used inconsistently. There was a high cognitive load as engineers needed to understand vast swathes of the system to make changes safely. Code was tightly coupled, making it difficult to isolate changes or deploy independently.
Our Approach: Starting Small After False Starts
We didn't succeed on our first attempt—or even our second. Over 12 months, we made several attempts to launch a DDD initiative, but each time the work stalled. The primary issue was that it felt too theoretical. Following the half dozen or so steps outlined in academic texts—working down to entities and aggregates, getting organisational buy-in, executing a reverse Conway maneuver—seemed overwhelming when balanced against immediate delivery pressures.
The key breakthrough came when we shifted our approach. Instead of attempting a complete transformation, we focused on identifying small, tangible benefits. We would create a reference model for use within the Product Architecture team and build from there. This pragmatic pivot gave us momentum.
The Workshop Challenge
We began with workshops within the Product Architecture team. Using collaborative modeling techniques, we mapped business capabilities onto bounded context candidates, iterating through several rounds of refinement. This process proved more challenging than anticipated.
The key tension was between reflecting the "as-is" state versus the cleaner vision state we aspired to reach. To get value from the effort - we needed to provide a vision for how things should be for a business with our business domains, but we needed to base it on how things are, why they are the way they are and extrapolate forward to how it should be if we had DDD from the start.
Our approach was to first document the as-is state briefly, then use it as input to design a to-be state that set a clear vision while respecting existing realities.
After establishing an initial model, we validated our thinking with senior product leaders first, then with senior engineering tech leads. This validation process helped refine the boundaries and ensured the model reflected business reality, not just technical architecture.
What We Identified
Our analysis revealed distinct bounded contexts that could be grouped into three main business categories:
Product Contexts – The customer-facing capabilities we sell:
- Recognition
- Ecommerce Store
Back-Office Contexts – Supporting internal business operations:
- Finance (fee configuration, invoicing, compliance)
- Order Management (shopping cart and order creation)
Supporting Service Contexts – Cross-cutting customer and user services:
- Tenant Management
- Customer Support
- Marketing
A fourth category emerged naturally: Technical and Platform Contexts. These provide frameworks, tooling, and technical services that support the business contexts but aren't themselves business domains.
For each of the (business) bounded contexts we identified their key entities, such as Award, Product, Order, fee, User, Customer and so on.
We captured this in a visual model—our "Contexts and Entities" diagram—showing the key entities within each context.
Bounded Context & Key Entities Sample
This high-level view became an invaluable reference artifact. Since its creation, this diagram has served as the foundation for architecture and engineering discussions across the organisation. Having one solid artifact upon which decisions could be made proved transformative for strategic conversations. In our implementation, entities within each bounded context typically corresponded to RESTful service endpoints, providing clear API boundaries.
Broader Outcomes
The bounded contexts framework became an organising principle that extended far beyond architecture diagrams. Teams used it to structure:
Monitoring dashboards organised by domain
On-call points of contact aligned with context ownership
Regression test suite organisation
GitLab group structures
AWS account organisation
Developer portal service catalog
Not everything succeeded. Some business entities we identified never fully materialised in the architecture. The full reverse Conway maneuver remains and outstanding goal and likely it will never be fully complete. Given today’s ever-changing business and technology landscape, if we can manage to map at least the critical areas, that’s probably okay.
But the successes significantly outweighed the losses. The value derived from our DDD work came primarily from the highest-level view—the bounded contexts themselves—leaving the deep entity modeling and aggregate design work for later with the teams. This pragmatic outcome validated our decision to start small and focus on tangible benefits.
The Surprising Win: Discovering an Unowned Key Supporting Domain
As we mapped dependencies between contexts, a pattern emerged. One particular bounded context appeared repeatedly as a dependency for many others, yet no team explicitly owned it: Customer Management (initially identified as "Tenants").
This context handled fundamental questions: Who are the users? Who are the customers? It was critical infrastructure, yet it lacked clear ownership, focused investment, or strategic attention. In DDD terms, Customer Management was an upstream context with multiple downstream consumers. Understanding these context mapping relationships helped us identify integration patterns and ownership boundaries
To build the case for addressing this gap, we turned to value chain analysis (Porter, 1985). Value chains map the components required to deliver user value and show dependencies.
Customer Management Dependencies and Value chain sample
We prepared a presentation for executive leadership that covered the following:
- Update to the bounded contexts we'd identified
- Business capabilities within each context
- Value chains underpinning key domains
- Analysis of organisational gaps and misalignments
The outcome was significant: formation of a new team dedicated to Customer Management, followed by organisational restructuring to align teams with this bounded context. This was our "reverse Conway maneuver" - reshaping the organisation to match the desired architecture rather than letting architecture mirror existing organisational structures. Granted, it was limited to this bounded context, but it was the key missing one as the rest of the context map for the most part already existed – they just needed some re-alignment around responsibilities.
Conclusion
Our journey with Domain-Driven Design taught us that you don't need 100% adherence to academic theory to derive substantial value. The strategic clarity gained from identifying and naming bounded contexts enabled better architectural decisions, clearer team ownership, and more focused business conversations.
By combining DDD principles with complementary value chain analysis—we created a powerful tool for organisational and technical alignment.
Takeaway
If you're considering a similar journey, our advice is straightforward: start small, focus on tangible benefits, and don't let the perfect be the enemy of the good. Even a high-level map of your bounded contexts can become an invaluable reference artifact that guides decisions for years.
What’s Your Story?
I’d love to learn from your experience. Have you been involved in a reverse Conway manoeuvre or a DDD-driven reorg? Drop your insights in the comments so others in the community can benefit from your journey.
Resources and References
- Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans (foundational work) and writings by Eric Evans on bounded contexts
- Value Chain Analysis – Understanding component dependencies and strategic positioning (https://miro.com/blog/value-chain-diagram/)
Without our humans, it’s just work.Opens in a new tab
About the author
Eddie Fitzpatrick
Eddie Fitzpatrick is the Director of Product Architecture at Workhuman. He has been with Workhuman for more than 18 years, during which time his team has guided the company’s technology strategy through multiple shifts, from server virtualisation to platform engineering, public cloud and, most recently, AI. Working closely with Product partners, they help shape the features and innovations that have established Workhuman as the leader in the recognition market. Outside of work, Eddie is an avid cyclist, runner and swimmer, and he believes that consistently pursuing and achieving new goals builds habits that carry over into every part of life.