Posts Tagged ‘DDD’
[NDCMelbourne2025] Preventing Emu Wars with Domain-Driven Design – Lee Dunkley
In an engaging and humorous presentation at NDC Melbourne 2025, Lee Dunkley explores how Domain-Driven Design (DDD) can prevent software projects from spiraling into chaotic, unmaintainable codebases—likening such failures to Australia’s infamous Emu War. By drawing parallels between historical missteps and common software development pitfalls, Lee illustrates how DDD practices, such as event storming and ubiquitous language, can steer teams toward solving the right problems, thereby enhancing maintainability and extensibility.
The Emu War: A Cautionary Tale for Coders
Lee begins with a whimsical analogy, recounting Australia’s 1930s Emu War, where soldiers armed with machine guns failed to curb an overwhelming emu population devastating crops. The emus’ agility and sheer numbers outmatched the military’s efforts, leading to a humbling defeat. Lee cleverly translates this to software development, where throwing endless code at a problem—akin to deploying infinite soldiers—often results in a complex, bug-ridden system. This sets the stage for his argument: without proper problem definition, developers risk creating their own unmanageable “emu wars.”
He illustrates this with a hypothetical coding scenario where a client demands a solution to “kill all the pesky emus.” Developers might churn out classes and methods, only to face mounting complexity and bugs, such as emus “upgrading to T-Rexes.” The lesson? Simply writing more code doesn’t address the root issue, much like the Emu War’s flawed strategy failed to protect farmers’ crops.
Modeling Smells in E-Commerce
Transitioning to a more practical domain, Lee applies the Emu War analogy to an e-commerce platform tasked with implementing an “update order” feature. Initially, the solution seems straightforward: create an endpoint to modify orders. However, as Lee demonstrates, this leads to bugs like customers receiving too many items, being undercharged, or getting empty boxes. These issues arise because the vague “update order” requirement invites a cascade of edge cases and race conditions.
By examining the system’s event timeline, Lee highlights how an “order updated” event disrupts critical processes like payment capture and stock reservation. This modeling smell—where a generic action undermines system integrity—mirrors the Emu War’s misaligned objectives. The real problem, Lee argues, lies in failing to define the business’s true needs, resulting in a codebase that’s hard to test and extend.
Refining with Domain-Driven Design
Here, Lee introduces DDD as a remedy, emphasizing techniques like event storming and the five whys to uncover the true problem space. Revisiting the Emu War, he applies the five whys to reveal that the goal wasn’t to kill emus but to secure employment for returning soldiers. Similarly, in the e-commerce case, the “update order” request masks specific needs: ensuring shoppers receive only desired items, adding forgotten items, and canceling orders.
By reframing these needs, Lee proposes targeted solutions, such as a “supplementary order” endpoint for adding items and a time-bound “order received” event to allow cancellations without disrupting the system. These solutions, rooted in DDD’s ubiquitous language, reduce complexity by aligning the code with business intent, avoiding the pitfalls of generic actions like “update.”
Simplicity Through Abstraction
Lee challenges the notion that complex problems demand complex solutions. Through DDD, he shows how elevating the level of abstraction—by focusing on precise business goals—eliminates unnecessary complexity. In the e-commerce example, replacing the problematic “update order” endpoint with simpler, purpose-specific endpoints demonstrates how DDD fosters maintainable, extensible code.
He acknowledges the challenges of implementing such changes in live systems, where breaking changes can be daunting. However, Lee argues that aligning solutions with the problem space is worth the effort, as it prevents the codebase from becoming a “Frankenstein’s monster” burdened by accidental complexity.
Conclusion: Avoiding Your Own Emu War
Lee wraps up by urging developers to wield their coding “superpower” wisely. Instead of burying problems under an avalanche of code, he advocates for DDD practices to ensure solutions reflect the business’s true needs. By employing event storming, refining ubiquitous language, and questioning requirements with the five whys, developers can avoid fighting futile, unmaintainable battles.
This talk serves as a compelling reminder that thoughtful problem definition is the cornerstone of effective software development. Lee’s blend of humor and practical insights makes a strong case for embracing DDD to create robust, adaptable systems.
[NDCOslo2024] Domain-Driven Design in Practice: How to Draw Your Domain Boundaries IRL – Vilde Opsal
In the dynamic crucible of organizational transformation, where business and technology converge, Vilde Opsal, an architect at FINN.no, narrates a saga of redrawing domain boundaries amidst a Nordic merger. As FINN.no and Schibsted Nordic Marketplaces shifted from horizontal silos to vertical units, Vilde orchestrated a domain-driven design (DDD) odyssey, harmonizing legacy maps with new strategies. Her case study, vibrant with real-world trials, illuminates how to craft domain boundaries that evolve with stakeholders, blending art, agility, and audience empathy.
Vilde frames her talk as a TV show, casting herself as the architect alongside product leads, developers, and a “big boss.” FINN.no’s reorganization—merging four marketplaces into a Nordic entity—demanded a new domain map to support independent verticals. Her mission: align historical domains, new teams, and strategic shifts, ensuring boundaries serve both immediate needs and long-term visions.
Crafting the Canvas: Principles of Domain-Driven Design
DDD, Vilde asserts, is an art, not a science. She begins with core tenets: domains as cohesive problem spaces, bounded contexts as clear partitions. At FINN.no, legacy boundaries—tied to functional areas like payments or listings—clashed with vertical ambitions. Her approach: engage stakeholders collaboratively, mapping domains via workshops that blend business goals with technical realities.
Vilde’s toolkit includes event storming, visualizing user journeys to delineate domains. For instance, real estate verticals prioritized distinct user journeys, while cars focused on transactional flows. This divergence necessitated tailored boundaries, ensuring each vertical’s autonomy while maintaining shared services like authentication.
Adapting to Audiences: Evolving Boundaries Over Time
Boundaries evolve, Vilde notes, as teams and goals shift. Early in the merger, real estate teams preserved legacy setups, minimizing disruption, while car verticals embraced user-centric journeys. She experimented with visualizations—temperature gauges, tables—to communicate progress, finding simplicity trumped flair. A table, mapping current versus aspirational states, resonated most, aligning diverse stakeholders.
Her insight: meet audiences where they are. Developers craved technical granularity; executives sought strategic clarity. By tailoring visualizations—diagrams for tech, narratives for business—Vilde bridged divides, ensuring domain maps clicked and stuck.
Balancing Pragmatism and Vision: Iterative Refinement
Pragmatism guided FINN.no’s journey. One vertical, pressed for time, made local decisions, deferring holistic reviews. Another, post-transformation, leaned on jobs-to-be-done, aligning domains to user needs. Vilde’s lesson: flexibility fosters progress. Iterative refinements, validated through experiments, ensured boundaries adapted to new stakeholders, like Nordic partners.
Her capstone: DDD thrives on dialogue. By fostering continuous feedback—workshops, retrospectives—teams co-create boundaries, balancing agility with coherence.
Embracing the Art: Making Domains Click
Vilde’s finale underscores DDD’s artistry: no universal blueprint exists. Success lies in experimentation, stakeholder alignment, and persistent iteration. Her challenge: craft domains that resonate, guiding teams from chaos to clarity with empathy and precision.
Links:
[NDCOslo2024] Reusable Ideas About the Reuse of Software – Audun Fauchald Strand & Trond Arve Wasskog
In the sprawling digital expanse of Norway’s welfare agency, NAV, where 143 million lines of code burgeon, Audun Fauchald Strand and Trond Arve Wasskog, principal engineers, confront the Sisyphean challenge of maintenance. Their discourse, a clarion call for strategic reuse, dissects NAV’s labyrinthine codebase, advocating for shared components to curb redundancy. With a nod to domain-driven design and Conway’s Law, Audun and Trond weave a narrative of organizational alignment, technical finesse, and cultural recalibration, urging a shift from ad-hoc replication to deliberate commonality.
NAV, serving Norway’s social safety net, grapples with legacy sprawl. Audun and Trond, seasoned navigators of this terrain, challenge the mantra “reuse should be discovered, not designed.” Their thesis: intentional reuse, underpinned by product thinking, demands ownership, incentives, and architecture harmonized with organizational contours. From open-source libraries to shared services, they map a spectrum of reuse, balancing technical feasibility with social dynamics.
Redefining Reuse: From Code to Culture
Reuse begins with understanding context. Audun outlines NAV’s scale: thousands of developers, hundreds of teams, and a codebase ballooning through modernization. Copy-pasting code—tempting for speed—breeds technical debt. Instead, they champion shared libraries and services, like payment gateways or journaling systems, already reused across NAV’s ecosystem. Open-source, they note, exemplifies external success; internally, however, reuse falters without clear ownership.
Trond delves into Conway’s Law: systems mirror organizational structures. NAV’s fragmented teams spawn siloed solutions unless guided by unified governance. Their solution: designate component owners, aligning incentives to prioritize maintenance over novelty. A payment service, reused across domains, exemplifies success, reducing duplication while enhancing reliability.
Technical Tactics and Organizational Orchestration
Technically, reuse demands robust infrastructure. Audun advocates platforms—centralized APIs, standardized pipelines—to streamline integration. Shared libraries, versioned meticulously, prevent divergence, while microservices enable modular reuse. Yet, technical prowess alone suffices not; social engineering is paramount. Trond emphasizes cross-team collaboration, ensuring components like letter-sending services are maintained by dedicated squads, not orphaned.
Their lesson: reuse is a socio-technical dance. Without organizational buy-in—financing, accountability, clear roles—components decay. NAV’s pivot to product-oriented teams, guided by domain-driven design, fosters reusable assets, aligning technical solutions with business imperatives.
Navigating Pitfalls: Ownership and Maintenance
The core challenge lies in the “blue box”—NAV’s monolithic systems. Audun and Trond dissect failures: reused components falter when unowned, leading to outages or obsolescence. Their antidote: explicit ownership models, where teams steward components, supported by funding and metrics. They cite successes—journaling services, payment APIs—where ownership ensures longevity.
Their vision: an internal open-source ethos, where teams contribute to and consume shared assets, mirrored by external triumphs like Kubernetes. By realigning incentives, NAV aims to transform reuse from serendipity to strategy, reducing code bloat while accelerating delivery.
Fostering a Reuse-First Mindset
Audun and Trond conclude with a cultural clarion: reuse thrives on intentionality. Teams must evaluate trade-offs—forking versus libraries, services versus platforms—within their context. Their call to action: join NAV’s mission, where reuse reshapes welfare delivery, blending technical rigor with societal impact.