Posts Tagged ‘DomainDrivenDesign’
[MunchenJUG] Architectural Decoupling: Practical Implementations of Persistence in Clean Architecture (13/May/2024)
Lecturer
Daniel Istvan Buza is a Senior Software Engineer and Technical Lead with extensive experience in the Java ecosystem. Currently leading two development teams, Daniel focuses on mentoring, code reviews, and hosting coding dojos to promote high-quality software craftsmanship. His technical expertise encompasses a wide array of technologies, including Microservices, Spring, Angular, Kafka, and MongoDB. Beyond his professional role, he is a frequent contributor to technical discourse, sharing insights through platforms like DZone and GitHub.
Abstract
While the theoretical foundations of Clean Architecture have been widely discussed since its inception by Robert C. Martin, practical implementation details—particularly concerning persistence—often remain elusive. This article examines the methodologies for decoupling business logic from technical infrastructure within Java-based systems. It explores the “dependency rule,” the strategic value of the business core, and the implications of making the domain agnostic of specific languages or frameworks. Central to this analysis is a non-standard, property-based approach to defining persistence APIs, designed to enhance modularity and maintainability in complex software environments.
The Philosophical Core of Clean Architecture
The essence of Clean Architecture lies in the strict management of dependencies, where the business core remains isolated from external technical influences. Robert Martin, often referred to as Uncle Bob, formalized this concept in 2012, emphasizing that business logic should not depend on the database, UI, or even the underlying programming language.
This decoupling is not merely a technical preference but a strategic business decision. In a software project, the primary value resides in the business rules. A system with a fully functional business core but no UI or database is more valuable and marketable than a system with a polished interface but no logic. By treating the business core as the primary asset, developers can defer decisions about specific frameworks or storage technologies, ensuring the system remains flexible and adaptable to future requirements.
Language and Framework Independence
A rigorous application of Clean Architecture suggests that the domain should ideally be expressed in a way that is independent of specific programming languages. While most systems are implemented in languages like Java or Python, some specialized environments, such as tax office systems, utilize domain-specific languages (DSLs) to encapsulate complex rules. This approach ensures that changes in the technical stack—such as upgrading a framework or migrating to a different runtime—do not force a redesign of the business logic.
Property-Based Persistence APIs
A significant challenge in implementing Clean Architecture is the interface between the domain and the persistence layer. Traditional approaches often couple the domain to specific database structures. A more flexible methodology involves defining a persistence API based on properties rather than fixed entities. This allows the domain to specify what data is needed without prescribing how it should be stored or retrieved.
By utilizing Java language features effectively, developers can create persistence abstractions that are both expressive and decoupled. This modularity facilitates easier testing, as the business logic can be verified in isolation using mocks or in-memory repositories without the overhead of a real database.
Conclusion
Transitioning from the theory of Clean Architecture to a sustainable implementation requires a disciplined approach to dependency management. By prioritizing the business core and utilizing property-based persistence abstractions, development teams can build systems that are resilient to technical churn. The ultimate goal is to create a codebase where the most valuable part of the software—its logic—is protected from the inevitable evolution of external tools and frameworks.
Links:
[VoxxedDaysBucharest2026] Ports, Adapters, and the Independence of Business Logic: George Patrașcu on Hexagonal Architecture in Practice
Lecturer
George Patrașcu is a seasoned software engineer at eMAG/CTO with more than twenty years of professional experience, including significant time in architectural leadership positions. Currently contributing to the Invoice and Payments platform team, George plays an active role in shaping internal developer guidelines and promoting sound architectural practices throughout a large organization characterized by hundreds of autonomous teams and diverse technology stacks.
Abstract
Within expansive microservices ecosystems featuring autonomous teams, frequent deployments, and heterogeneous technologies, business logic commonly becomes entangled with infrastructure specifics, yielding systems that are difficult to maintain, evolve, or understand. George Patrașcu presents Hexagonal Architecture—also recognized as Ports and Adapters—as a pragmatic methodology for protecting core domain logic from external dependencies including relational databases, RESTful services, event streams such as Kafka, and various third-party integrations. Grounded firmly in production realities at eMAG, the session provides balanced coverage of conceptual foundations, detailed C# implementation examples, testing approaches, and honest discussion of trade-offs encountered in practice.
The Challenges of Traditional Layered Architectures in Evolving Systems
Conventional layered architectures consisting of presentation, business, and data access tiers deliver initial value for straightforward applications. However, sustained growth across hundreds of teams utilizing varied languages (Java, .NET, Python, Scala), communication mechanisms (REST, Kafka), and continuous integration practices exposes fundamental weaknesses.
Business rules gradually permeate multiple layers: service classes reference persistence entities directly, controllers embed data access logic, and external service contracts influence domain models. Bounded contexts, a cornerstone of Domain-Driven Design, demand careful translation through anti-corruption layers, yet traditional designs frequently fail to maintain clean separation.
Resulting issues include duplicated business logic across backend-for-frontend components, mobile client platforms, and core services; severely compromised unit testing due to pervasive infrastructure dependencies; and cascading changes whenever external contracts, database schemas, or framework versions evolve. Simple folder structures offer no enforceable boundaries, while multi-module projects introduce tedious mapping layers that increase cognitive load.
Core Concepts of Hexagonal Architecture: Ports, Adapters, and the Application Core
Hexagonal Architecture fundamentally inverts dependency direction to position the domain model at the center. Business logic and associated domain entities reside within the core, depending exclusively upon abstract ports rather than concrete implementations. Input ports, implemented by driving adapters (REST controllers, message consumers), expose use cases to external actors. Output ports, realized by driven adapters (repositories, external clients), allow the core to interact with infrastructure without awareness of underlying details.
This structure adheres strictly to the Dependency Inversion Principle: high-level policy (domain) remains independent of low-level mechanisms (infrastructure). The hexagonal representation visually encapsulates the core, with ports serving as interfaces through which adapters connect. Domain objects and language remain pure, expressed in business terms rather than technical artifacts.
Flexible structuring accommodates varying scales: monolithic single projects for initial simplicity, separation of adapters by technical domain (isolating payment processors or external APIs), or evolution from modular monoliths toward independent microservices. This “build modular from the start” philosophy supports rapid feature development followed by natural service extraction when boundaries emerge.
Implementation Details, Trade-offs, and Testing Strategies
Practical development begins with domain modeling. For a rescue fleet management system, an AssembleFleet input port defines the primary use case contract. Implementation within a domain service orchestrates inventory retrieval and selection logic expressed purely in business concepts.
Driven adapters address external complexities: a Swappy client manages API pagination, performs type coercions (string passenger counts to domain integers), and implements anti-corruption filtering for inconsistent partner data. Custom domain annotations (@DomainService) facilitate integration with dependency injection frameworks without introducing technical concerns into the core.
Persistence strategies favor rich domain models mapped via ORM capabilities (e.g., shadow properties, complex types), minimizing dual maintenance of entities. This preserves core purity while leveraging framework strengths.
Testing follows clear separation: exhaustive unit tests exercise domain logic in complete isolation, while integration tests utilize fakes and mocks for adapters, verifying translation correctness without external system dependencies.
Trade-offs warrant careful consideration. The pattern excels with rich domain models containing substantial behavior but may introduce unnecessary indirection for straightforward query-dominant services. Hybrid approaches applying hexagonal principles selectively to complex logic paths, combined with CQRS separation or vertical slice organization, often prove optimal. The speakers caution against architectural dogmatism—context, team maturity, and problem complexity should guide application extent.
Architectural fitness functions, implemented via tools like ArchUnit, provide automated verification of boundaries even when AI assistance generates code.
Implications for Autonomous Teams and Long-Term Maintainability
Within large organizations featuring hundreds of developers operating with significant autonomy and minimal centralized control, Hexagonal Architecture strikes an effective balance. Teams retain freedom in implementation details while benefiting from consistency promoted through architecture guilds and shared guidelines. The pattern facilitates technology migration, incremental refactoring, and clear delineation of responsibilities.
By maintaining domain logic independent of infrastructure specifics, services demonstrate greater resilience to external changes—whether API contract updates, database platform shifts, or new integration requirements. This aligns naturally with trunk-based development, feature flag strategies, and high-frequency deployment practices, enhancing overall organizational agility.
Not every service necessitates complete hexagonal purity. Selective application targeting areas of highest coupling delivers outsized returns in testability, evolvability, developer onboarding speed, and long-term maintenance costs.
Links:
[PyDataGlobal2025] The Lifecycle of a Jupyter Environment: From Exploratory Notebook to Production Pipeline
Lecturer
Dawn Wages is Director of Community and Developer Relations at Anaconda. She brings a background that spans business education, software development, and sustained open-source community work within the Python Software Foundation, NumFOCUS, and SciPy ecosystems. Her professional focus includes developer advocacy, packaging sustainability, and the practical maturation of data-science workflows from initial exploration to reliable production systems.
Abstract
Most machine-learning and data-science projects begin life as a Jupyter notebook—an interactive space for curiosity-driven exploration and rapid prototyping. The transition from that exploratory artifact to a reliable, scheduled, and maintainable pipeline introduces a series of engineering, organizational, and infrastructural challenges. This article traces the full lifecycle: the establishment of clear objectives and documentation practices, the modularization of notebook logic into reusable and testable components, the selection of appropriate tooling matched to concrete workflow needs, the maintenance of reproducible computational environments, and the deployment of resilient production systems. Emphasis is placed on domain-driven design principles, established software-engineering patterns, and the complementary roles of notebooks, scripts, configuration files, and managed cloud platforms.
Establishing Objectives, Documentation, and Shared Language
Projects that begin with solitary tinkering frequently carry forward unspoken assumptions that later prove costly to reverse. A brief but structured kickoff conversation that surfaces domain expertise, distinguishes desired outcomes from tangible outputs, and establishes a clear matrix of responsibilities (responsible, accountable, consulted, informed) can prevent weeks of misdirected effort. Documentation is treated not as an afterthought but as a primary project artifact; code follows conversation rather than the reverse. Incremental milestones are framed as opportunities for collective recognition rather than mere accountability checkpoints, fostering a collaborative rather than adversarial atmosphere.
Domain-driven design supplies a particularly useful vocabulary for this stage. Variable names, module boundaries, data contracts, and even file-system organization should reflect the language of the subject-matter experts rather than the transient notational convenience of the analyst. When nomenclature diverges from domain concepts, the mismatch itself becomes diagnostic of incomplete understanding and signals the need for further dialogue. Early attention to platform constraints and resource limits also surfaces at this stage, allowing teams to anticipate hardware, cost, and scalability considerations before architectural commitments harden.
Modularization, Architectural Patterns, and the Separation of Concerns
Once objectives stabilize, the notebook is systematically decomposed. Reusable fragments of logic are extracted into pure functions that possess explicit inputs and outputs; these functions then migrate into ordinary Python modules, shell scripts, or declarative configuration files. The notebook itself shrinks to a thin orchestration layer that imports and invokes the modular components. With clear boundaries in place, unit tests become feasible, and the chronic difficulty of knowing which cells must be executed in which order largely disappears.
Two illustrative patterns recur across successful transitions. A builder-style class for an ETL pipeline accumulates ordered steps—extraction, validation, cleaning, transformation, feature engineering—and executes them in sequence, providing a readable and extensible scaffold. Training and evaluation logic is likewise encapsulated in dedicated classes that accept data, produce fitted models, perform cross-validation, and return quantitative comparisons. Both patterns draw on established software-architecture literature and on mature libraries such as scikit-learn, allowing practitioners to leverage battle-tested abstractions rather than reinventing core functionality. The resulting structure supports maintainability, testability, and eventual scaling while preserving the interactive character of the original exploratory work.
Tool Selection, Environment Reproducibility, and Hardware Considerations
No single tooling stack is universally optimal; the decisive criterion is fit to the concrete workflow rather than current popularity. Papermill enables parameterized execution of notebooks, supporting batch reporting, systematic variation of data sets, and lightweight A/B testing without abandoning the notebook paradigm. MLflow supplies experiment tracking, model versioning, and a lightweight registry, reducing the risk that promising configurations are lost. Managed platforms such as Snowflake, Amazon SageMaker, or Azure reduce the operational burden of infrastructure provisioning while introducing cost-visibility dashboards that help prevent unexpected expenditure.
Environment reproducibility remains a persistent and under-appreciated difficulty. The Python packaging ecosystem continues to evolve; initiatives such as wheel-next seek to improve the handling of system-level libraries that pip alone cannot reliably manage. Project-local environment managers keep dependencies co-located with source code and thereby improve portability, while global environments remain useful for shared tooling. GPU-accelerated libraries such as RAPIDS can accelerate familiar pandas-style workflows without requiring code changes, provided the underlying hardware is available—either on local machines or through cloud providers that expose appropriate accelerators. Binary dependencies and conflicts among system libraries continue to demand careful attention, especially when multiple packages link against incompatible versions of the same underlying C or C++ library.
Deployment Practices, Resilience, and Closing the Feedback Loop
Production systems require automated testing, staged rollbacks, health checks, and continuous monitoring. Idempotent pipeline steps, retry logic protected by rate limiting or load shedding, and feature flags reduce the blast radius of individual failures. Logging, metrics, and alerting—standard offerings of major cloud providers—close the observational feedback loop. Pipeline design must simultaneously consider task complexity, hardware constraints, collaborative experimentation needs, developer-tooling preferences, and the requirements of downstream applications. A concise reference checklist covering these dimensions proves valuable at the start of each new project.
Interactive visualization layers—PyScript for in-browser Python execution, Voilà, Panel, and the HoloViz ecosystem—extend the lifecycle beyond batch pipelines into stakeholder-facing dashboards. In this way the original notebook, once a private exploratory artifact, becomes the seed of a living, shareable system that supports both scheduled production runs and ad-hoc investigation.
Links:
[VoxxedDaysTicino2026] Why Hexagonal and Onion Architectures Are Answers to the Wrong Question
Lecturer
Oliver Drotbohm is a senior principal software engineer at Broadcom, formerly part of the Spring engineering team at VMware for over 15 years. He has contributed significantly to Spring Data, focusing on repository abstractions, and more recently on architectural topics like Spring Modulith. Oliver is an advocate for modular software design and has spoken extensively on domain-driven design and system architecture. Relevant links include his GitHub profile (https://github.com/odrotbohm) and X account (https://x.com/odrotbohm).
Abstract
This article delves into Oliver Drotbohm’s critique of popular separation-of-concerns architectures like hexagonal and onion models, arguing they often prioritize decoupling over cohesion, leading to suboptimal code structures. Through theoretical analysis and practical examples, it explores software design principles rooted in coupling, cohesion, and anticipated changes. The discussion highlights trade-offs, the role of tools like Spring Modulith, and advocates for functional decomposition to achieve maintainable systems.
Fundamental Principles of Software Design and Cost
Software development’s primary cost lies in modifications rather than initial creation, as most efforts involve evolving existing systems. Oliver draws from Kent Beck’s interpretation of Edward Yourdon and Larry Constantine’s work, positing that change costs are tied to coupling between code elements—classes, packages, or modules. Coupling manifests when alterations in one area necessitate changes elsewhere, with its nature depending on the change type (e.g., database migration versus UI enhancement).
To minimize costs, decoupling is essential, but it introduces its own overhead, such as additional interfaces and implementations. Oliver emphasizes cohesion as the counterbalance: intentional coupling in appropriate places to collocate elements for common changes. Effective design creates cohesive units loosely coupled to others, essentially betting on future change patterns.
Systems emerge not just from parts but their interactions, per Russell Ackoff’s philosophy. Thus, design involves defining cohesive elements, promoting entry points, and establishing connections. This foundational view critiques architectures that overlook these dynamics.
Critique of Separation-of-Concerns Architectures
Hexagonal architecture, coined by Alistair Cockburn in 2005, centers domain logic, shielding it from infrastructure via ports and adapters. Ports are neutral entry points, with adapters depending on them, inverting dependencies to isolate the core. Onion architecture, by Jeffrey Palermo in 2008, similarly layers domain, application, and infrastructure, omitting explicit ports but maintaining inward dependencies.
Oliver compares these to layered architectures from domain-driven design (DDD), where presentation, business, and persistence layers interact, with business potentially depending on infrastructure. The key difference is dependency inversion, but terminology shifts obscure similarities. Spring applications historically embodied this: controllers (presentation/adapters), services (business/ports), repositories (persistence).
Yet, these models often yield complexity, with excessive folders for adapters, contradicting their goal of clarifying business logic. Oliver argues they answer the wrong question—focusing on technical separation rather than business cohesion.
Alternative Approaches: Prioritizing Cohesion and Encapsulation
Instead of technical layers as primary packages or modules, Oliver advocates functional decomposition, grouping by business slices (e.g., order, customer). This avoids scattering related elements across layers, akin to organizing furniture by type rather than function.
In code, vertical slices encapsulate internals: controllers, services, repositories within one package, hidden by default visibility. Public interfaces expose only necessary surfaces, enhancing encapsulation over mere organization. For simple read-only scenarios, direct JDBC in controllers suffices, hidden from outsiders. Complex slices warrant internal abstractions.
This yields cohesive bases automatically decoupled, as inter-slice connections are minimal. Intrinsic complexity dictates accidental complexity—pragmatic layering per slice. Tools like Spring Modulith enforce this, using annotations for stereotypes (e.g., @AggregateRoot), integrating with IDEs to display architectural concepts beyond packages.
Trade-Offs, Tools, and Implications
Trade-offs include initial simplicity versus future adaptability: technical packages force public interfaces, risking violations, while functional ones hide more, supporting evolution. Oliver notes developers’ inclination toward technical structures stems from IDEs’ technology-centric views (e.g., source/main/java), lacking higher abstractions.
Spring Modulith and ArchUnit address this, verifying rules and visualizing modules. IDE integrations (VS Code, Eclipse) convey code via design stereotypes, reducing package reliance.
Implications favor cohesion-first design: functional decomposition aligns with change patterns, reducing scattering. It supports DDD aggregates and repositories naturally, without mandating architectures. As systems grow, this prevents tangled messes from entangled business logic, not just direct database calls.
In conclusion, reframing the question from decoupling infrastructure to fostering cohesive, change-resilient structures yields maintainable software, leveraging tools for integrity.
Links:
[NDCMelbourne2025] TDD & DDD from the Ground Up – Chris Simon
Chris Simon, a seasoned developer and co-organizer of Domain-Driven Design Australia, presents a compelling live-coding session at NDC Melbourne 2025, demonstrating how Test-Driven Development (TDD) and Domain-Driven Design (DDD) can create maintainable, scalable software. Through a university enrollment system example, Chris illustrates how TDD’s iterative red-green-refactor cycle and DDD’s focus on ubiquitous language and domain modeling can evolve a simple CRUD application into a robust solution. His approach highlights the power of combining these methodologies to adapt to changing requirements without compromising code quality.
Starting with TDD: The Red-Green-Refactor Cycle
Chris kicks off by introducing TDD’s core phases: writing a failing test (red), making it pass with minimal code (green), and refactoring to improve structure. Using a .NET-based university enrollment system, he begins with a basic test to register a student, ensuring a created status response. Each step is deliberately small, balancing test and implementation to minimize risk. This disciplined approach, Chris explains, builds a safety net of tests, allowing confident code evolution as complexity increases.
Incorporating DDD: Ubiquitous Language and Domain Logic
As the system grows, Chris introduces DDD principles, particularly the concept of ubiquitous language. He renames methods to reflect business intent, such as “register” instead of “create” for students, and uses a static factory method to encapsulate logic. His IDE extension, Contextive, further supports this by providing domain term definitions across languages, ensuring consistency. By moving validation logic, like checking room availability, into domain models, Chris ensures business rules are encapsulated, reducing controller complexity and enhancing maintainability.
Handling Complexity: Refactoring for Scalability
As requirements evolve, such as preventing course over-enrollment, Chris encounters a race condition in the initial implementation. He demonstrates how TDD’s tests catch this issue, allowing safe refactoring. Through event storming, he rethinks the domain model, delaying room allocation until course popularity is known. This shift, informed by domain expert collaboration, optimizes resource utilization and eliminates unnecessary constraints, showcasing DDD’s ability to align code with business needs.
Balancing Testing Strategies
Chris explores the trade-offs between API-level and unit-level testing. While API tests protect the public contract, unit tests for complex scheduling algorithms allow faster, more efficient test setup. By testing a scheduler that matches courses to rooms based on enrollment counts, he ensures robust logic without overcomplicating API tests. This strategic balance, he argues, maintains refactorability while addressing intricate business rules, a key takeaway for developers navigating complex domains.
Adapting to Change with Confidence
The session culminates in a significant refactor, removing the over-enrollment check after realizing it’s applied at the wrong stage. Chris’s tests provide the confidence to make this change, ensuring no unintended regressions. By making domain model setters private, he confirms the system adheres to DDD principles, encapsulating business logic effectively. This adaptability, driven by TDD and DDD, underscores the value of iterative development and domain collaboration in building resilient software.
Links:
[DevoxxBE2025] Live Coding The Hive: Building a Microservices-Ready Modular Monolith
Lecturer
Thomas Pierrain is Vice President of Engineering at Agicap, a financial management platform, where he applies domain-driven design to build scalable systems. Julien Topcu is Vice President of Technology at SHODO Group, a consultancy focused on socio-technical coaching and architecture, with expertise in helping teams implement domain-driven practices.
Abstract
This analysis investigates the Hive pattern, an architectural approach for creating modular monoliths that support easy evolution to microservices. It identifies key ideas like vertical slicing and port-adapter boundaries, set against the backdrop of microservices pitfalls. Highlighting a live-refactored time-travel system, it details methods for domain alignment, encapsulation, and simulated distributed communication. Consequences for system flexibility, debt management, and scalability are evaluated, providing insights into resilient designs for existing and new developments.
Emergence from Microservices Challenges
Over a decade, the shift to microservices has often resulted in distributed messes, worse than the monoliths they replaced due to added complexity in coordination and deployment. The modular monolith concept arises as a remedy, but risks tight coupling if not properly segmented. The Hive addresses this by separating design from deployment, following “construct once, deploy flexibly.”
In the live example, a time-machine’s control system—handling energy, navigation, and diagnostics—crashes due to fragility, landing in the 1980s. Diagnostics reveal a muddled structure with high resource use, mirroring legacy systems burdened by modeling debt—the buildup of imprecise domain models hindering change.
The pattern’s innovation lies in fractal composability: modules as hexagons can nest or extract as services. This enables scaling in (sub-modules) or out (microservices), adapting to needs like independent deployment for high-load components.
Essential Tenets of the Hive
Vertical slicing packs modules with all necessities—logic, storage, interfaces—for self-sufficiency, avoiding shared layers’ dependencies. In the demo, the energy module includes its database, isolating it from navigation.
Port-adapter encapsulation defines interaction points: inbound for incoming, outbound for outgoing. Adapters translate, eliminating direct links. The navigation’s energy request port uses an adapter to call the energy’s provision port, preventing tangles.
Inter-module talks mimic microservices sans networks, using in-process events. This readies for distribution: swapping adapters for remote calls extracts modules seamlessly. The example routes via a bus, allowing monolith operation with distributed readiness.
These tenets create a supple framework, resilient to evolution. The fractal aspect allows infinite composition, as shown by nesting diagnostics within navigation.
Refactoring Methodology and Practical Steps
The session starts with a monolithic system showing instability: overused resources cause anomalies. AI schemas expose entanglements, guiding domain identification—energy, time circuits, AI.
Modules reorganize: each hexagon sliced vertically with dedicated storage. Code moves via IDE tools, databases split to prevent sharing. Energy gains PostgreSQL, queried through adapters.
Communication restructures: ports define contracts, adapters implement. Navigation’s outbound energy port adapts to energy’s inbound, using events for asynchrony.
Extraction demonstrates: energy becomes a microservice by changing adapters to network-based, deploying separately without core changes. Tests modularize similarly, using mocks for isolation.
This step-by-step approach handles brownfields incrementally, using tools for safe restructuring.
Resilience, Scalability, and Debt Mitigation
Hive’s boundaries enhance resilience: changes localize, as energy tweaks affect only its hexagon. This curbs debt, allowing independent domain refinement.
Scalability is fractal: inward nesting subdivides, outward extraction distributes. Networkless talks ease transitions, minimizing rewrites.
Versus monoliths’ coupling or microservices’ prematurity, Hive balances, domain-focused for “right-sized” architectures. Challenges: upfront refactoring, boundary discipline.
Development Ramifications and Adoption
Hive promotes adaptive designs for changing businesses. Starting modular prevents debt in new projects; modernizes legacies via paths shown.
Wider effects: better sustainment, lower costs through contained modules. As hype fades, Hive provides hybrids, emphasizing appropriate sizing.
Future: broader use in frameworks, tools for pattern enforcement.
In overview, Hive exemplifies composable resilience, merging monolith unity with microservices adaptability.
Links:
- Lecture video: https://www.youtube.com/watch?v=VKcRNtj0tzc
- Thomas Pierrain on LinkedIn: https://fr.linkedin.com/in/thomas-p-0664769
- Thomas Pierrain on Twitter/X: https://twitter.com/tpierrain
- Julien Topcu on LinkedIn: https://fr.linkedin.com/in/julien-top%25C3%25A7u
- Agicap website: https://agicap.com/
- SHODO Group website: https://shodo.io/
[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.
[DevoxxBE2023] REST Next Level: Crafting Domain-Driven Web APIs by Julien Topçu
At Devoxx Belgium 2023, Julien Topçu, a technical coach at Shadow, delivered a compelling session on elevating REST APIs by embedding domain-driven design principles. With a rich background in crafting software using Domain-Driven Design (DDD), Extreme Programming, and Kanban, Julien illuminated the pitfalls of traditional REST implementations and proposed a transformative approach to encapsulate business intent within APIs. His talk, centered around a fictional space travel booking system, demonstrated how to align APIs with user actions, preserve business workflows, and enhance consumer experience through hypermedia controls. Through a blend of theoretical insights and practical demonstrations, Julien showcased a methodology to create APIs that are not only functional but also semantically rich and workflow-driven.
The Pitfalls of Traditional REST APIs
Julien began by highlighting a pervasive issue in software architecture: the loss of business intent when translating domain logic into REST APIs. Typically, business logic resides in the backend to avoid duplication across consumers like web or mobile applications. However, REST’s uniform interface, with its limited vocabulary of CRUD operations (Create, Read, Update, Delete), often distorts this logic. For instance, in a train reservation system, a user’s intent to “search for trains” is reduced to “create a search resource,” stripping away domain-specific semantics like destinations or schedules. This mismatch, Julien argued, stems from REST’s standardized approach, formalized by Roy Fielding in his PhD thesis, which prioritizes simplicity over application-specific needs. As a result, APIs lose expressiveness, forcing consumers to reconstruct business workflows, leading to what Julien termed “accidental complexity of adaptation.”
To illustrate, Julien presented a scenario where a user performs a search for space trains from Earth to the Moon. The traditional REST API translates this into a POST request to create a search resource, devoid of domain context. This not only obscures the user’s intent but also couples consumers to the backend’s implementation, making changes—like switching from “bound” to “journey index” for multi-destination trips—disruptive. Julien’s live demo underscored this fragility: altering a request parameter broke the API, highlighting the risks of tight coupling between consumers and backend models.
Encapsulating Business Intent with Semantic Endpoints
To address these shortcomings, Julien proposed aligning REST endpoints with user actions rather than backend models. Instead of exposing implementation details, such as updating a sub-resource like “selection” within a search, APIs should reflect behaviors like “select a space train with a fare.” This approach involves using classifiers in URLs, such as POST /searches/{id}/spacetrains/{number}/fares/{code}/select, which clearly convey the intent of selecting a fare for a specific train. Julien emphasized that this does not violate REST principles, debunking the myth that verbs in URLs are forbidden. As long as verbs align with HTTP methods (e.g., POST for creating a resource), they enhance semantic clarity without breaking the uniform interface.
This shift decouples consumers from the backend’s internal structure. For example, changing the backend’s data model (e.g., using booleans instead of a selection object) no longer impacts consumers, as the API exposes behaviors rather than state. Julien’s demo further showcased this by demonstrating how a frontend could adapt to backend changes (e.g., from “bound” to “journey index”) without modification, thanks to semantic endpoints. This approach not only preserves business intent but also simplifies consumer logic, reducing the cognitive load of interpreting CRUD-based APIs.
Encapsulating Workflows with Hypermedia Controls
A critical challenge Julien addressed is the lack of workflow definition in traditional REST APIs. Typically, consumers must hardcode business workflows, such as the sequence of selecting outbound and inbound trains before booking. This leads to duplicated logic and potential errors, like displaying a booking button prematurely. Julien introduced hypermedia controls, specifically HATEOAS (Hypermedia As The Engine Of Application State), as a solution. By embedding links in API responses, the backend can guide consumers through the workflow dynamically.
In his demo, Julien showed how a search response includes links like select-outbound and all-inbounds, which guide the consumer to the next valid actions. For instance, after selecting an outbound train, the response provides a link to select an inbound train, ensuring only compatible options are available. This encapsulation of workflow logic in the backend eliminates the need for consumers to understand the sequence of actions, reducing errors and enhancing maintainability. Julien highlighted that this approach, part of the Richardson Maturity Model’s Level 3, makes APIs discoverable and resilient to backend changes, as consumers rely on links rather than hardcoded URLs.
Practical Implementation and Limitations
Julien’s live coding demo brought these concepts to life, showcasing a Spring Boot backend in Kotlin that dynamically generates links based on the application state. For example, the create-booking link only appears when the selection is complete, ensuring consumers cannot book prematurely. This dynamic guidance, facilitated by Spring HATEOAS, allows the frontend to display UI elements like the booking button based solely on available links, streamlining development and enhancing user experience.
However, Julien acknowledged limitations. For complex forms requiring extensive user input, the hypermedia approach may need supplementation with predefined payloads, as consumers must know what data to send. Additionally, long URLs, while not a practical issue in Julien’s experience at Expedia, could pose challenges in some contexts. Despite these constraints, the approach excels in domains with well-defined workflows, offering a robust framework for building expressive, maintainable APIs.
Conclusion: A New Paradigm for REST APIs
Julien’s session at Devoxx Belgium 2023 offered a transformative vision for REST APIs, emphasizing the power of domain-driven design and hypermedia controls. By aligning endpoints with user actions, encapsulating behaviors, and guiding workflows through links, developers can create APIs that are both semantically rich and resilient to change. This approach not only enhances consumer experience but also aligns with the principles of DDD, ensuring that business intent remains at the forefront of API design. Julien’s practical insights and engaging demo left attendees inspired to rethink their API strategies, fostering a deeper appreciation for REST’s potential when infused with domain-driven principles.
Links:
[PHPForumParis2022] Exploring DDD and Functional Programming Practices – Benjamin Rambaud
Benjamin Rambaud, an accomplished PHP engineer at ekino, delivered an engaging presentation at PHP Forum Paris 2022, inviting developers to explore Domain-Driven Design (DDD) and functional programming to enhance their craft. With a nod to the collaborative spirit of the event, Benjamin adopted a market-like metaphor, encouraging attendees to “pick and choose” principles from DDD and functional programming to enrich their PHP projects. His talk, informed by his role as a co-organizer of AFUP Bordeaux, offered practical insights into improving code quality and project communication, drawing from established methodologies while urging developers to adapt them thoughtfully.
Foundations of Domain-Driven Design
Benjamin opened by demystifying DDD, a methodology focused on modeling complex business domains with precision. He emphasized the Ubiquitous Language, a shared vocabulary that aligns developers, stakeholders, and domain experts, fostering clearer communication. By prioritizing domain logic over technical details, DDD isolates business rules, making code more maintainable and expressive. Benjamin illustrated this with examples from his work at ekino, showing how DDD’s strategic patterns, like bounded contexts, help developers encapsulate business logic effectively, reducing framework dependency.
Leveraging Functional Programming
Shifting to functional programming, Benjamin highlighted its synergy with PHP’s multi-paradigm nature. He introduced concepts like pure functions, immutability, and value objects, which enhance testability and predictability. By integrating these principles, developers can create robust, error-resistant codebases. Benjamin drew from his experience with Drupal, demonstrating how functional programming complements DDD by isolating domain logic from framework-specific code, allowing for greater flexibility and maintainability in PHP projects.
Practical Implementation and Hexagonal Architecture
Delving into practical applications, Benjamin advocated for hexagonal architecture as a cornerstone of DDD in PHP. This approach uses ports and adapters to decouple business logic from external systems, enabling seamless integration with frameworks like Symfony. He cautioned against rigid adherence to frameworks, referencing resources like Mathias Verraes’ blog for deeper insights into DDD patterns. Benjamin’s practical advice, grounded in real-world examples, encouraged developers to experiment with repositories and interfaces tailored to their project’s needs, fostering adaptable and resilient code.
Balancing Frameworks and Principles
Concluding, Benjamin urged developers to understand their frameworks deeply while embracing external paradigms to avoid being constrained by default configurations. He emphasized that DDD and functional programming are not rigid doctrines but flexible tools to be adapted contextually. By encouraging exploration of languages like Elixir or OCaml, Benjamin inspired attendees to broaden their perspectives, enhancing their ability to craft high-quality, business-aligned PHP applications through thoughtful experimentation.
Links:
[SpringIO2023] Spring is Bootiful but So is Your Domain: Michael Plöd’s Call to Action
At Spring I/O 2023 in Barcelona, Michael Plöd delivered an engaging and unconventional talk that urged developers to step beyond their technical comfort zones and dive into the business domains they serve. Departing from the typical code-heavy sessions of the conference, Michael, a fellow at InnoQ and a long-time Spring user, emphasized the transformative power of understanding business contexts. Through interactive polls, real-world anecdotes, and practical strategies, he inspired attendees to become more valuable developers by aligning their technical expertise with business needs, ultimately enhancing code quality, team collaboration, and product impact.
The Value of Domain Knowledge
Michael opened by challenging the audience to reflect on their motivations for becoming software engineers, humorously acknowledging the allure of financial rewards but quickly pivoting to a deeper point: developers who grasp their business domain become significantly more valuable. He argued that domain knowledge enables better design choices, from writing maintainable code to making informed modularization decisions. By understanding the business, developers can create software that aligns with organizational goals, reducing friction and enhancing agility. Michael’s interactive poll revealed that many attendees had only a partial understanding of their business models, underscoring the need for greater curiosity about customer segments, value propositions, and revenue streams.
Writing Maintainable Code Through Domain Alignment
A standout moment was Michael’s recounting of a formative experience as a young developer at a bank, tasked with building a mortgage loan scoring engine. Initially, he relied on a detailed 50-page specification, structuring the code around assumed rules for points and no-go criteria. However, during acceptance testing, discrepancies emerged, revealing a mismatch between his mental model and the risk managers’ perspective. By directly engaging with the risk managers and refactoring the code to reflect their clustered rule structure, Michael transformed a complex change into a straightforward task. This story highlighted the importance of understanding the business’s mental model, reducing implicit assumptions, and structuring code to mirror domain logic, resulting in more maintainable and adaptable software.
Improving Modularization and Communication
Michael emphasized that domain knowledge informs better modularization decisions, particularly in architectures like microservices or serverless systems. He cited the Accelerate book, which links loosely coupled architectures to high-performing IT organizations, suggesting that aligning modules with business domains enhances team autonomy and delivery speed. Another poll showed strong audience agreement that modularization impacts value propositions, reinforcing the need to consider business goals when defining module boundaries. On communication, Michael cautioned against using technical jargon that alienates business stakeholders, advocating for empathy and clear language. He shared an amusing example of a fashion retailer where database table names leaked into sales floor terminology, illustrating the pitfalls of disconnected communication.
Influencing Product Design
The talk culminated in a call to influence product design through domain expertise. Michael argued that developers who understand business problems can propose solutions that enhance user experiences or create new business models. He referenced Marty Cagan’s research, which identifies direct customer feedback as a top source for product ideas, suggesting developers contribute more than just code. A final poll on digitalization revealed varied interpretations, from paperless processes to business model innovation, prompting Michael to stress that both improving existing models and creating new ones require close collaboration between technology and business teams. By fostering curiosity and asking questions, developers can bridge this gap, driving meaningful digital transformation.