Posts Tagged ‘DomainDrivenDesign’
[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:
[DevoxxUS2017] The Hardest Part of Microservices: Your Data by Christian Posta
At DevoxxUS2017, Christian Posta, a Principal Middleware Specialist at Red Hat, delivered an insightful presentation on the complexities of managing data in microservices architectures. Drawing from his extensive experience with distributed systems and open-source projects like Apache Kafka and Apache Camel, Christian explored how Domain-Driven Design (DDD) helps address data challenges. His talk, inspired by his blog post on ceposta Technology Blog, emphasized the importance of defining clear boundaries and leveraging event-driven technologies to achieve scalable, autonomous systems. This post delves into the key themes of Christian’s session, offering a comprehensive look at navigating data in microservices.
Understanding the Domain with DDD
Christian Posta began by addressing the critical need to understand the business domain when building microservices. He highlighted how DDD provides a framework for modeling complex domains by defining bounded contexts, entities, and aggregates. Using the example of a “book,” Christian illustrated how context shapes data definitions, such as distinguishing between a book as a single title versus multiple copies in a bookstore. This clarity, he argued, is essential for enterprises, where domains like insurance or finance are far more intricate than those of internet giants like Netflix. By grounding microservices in DDD, developers can create explicit boundaries that align with business needs, reducing ambiguity and fostering autonomy.
Defining Transactional Boundaries
Transitioning to transactional boundaries, Christian emphasized minimizing the scope of atomic operations to enhance scalability. He critiqued the traditional reliance on single, ACID-compliant databases, which often leads to brittle systems when applied to distributed architectures. Instead, he advocated for identifying the smallest units of business invariants, such as a single booking in a travel system, and managing them within bounded contexts. Christian’s insights, drawn from real-world projects, underscored the pitfalls of synchronous communication and the need for explicit boundaries to avoid coordination challenges like two-phase commits across services.
Event-Driven Communication with Apache Kafka
A core focus of Christian’s talk was the role of event-driven architectures in decoupling microservices. He introduced Apache Kafka as a backbone for streaming immutable events, enabling services to communicate without tight coupling. Christian explained how Kafka’s publish-subscribe model supports scalability and fault tolerance, allowing services to process events at their own pace. He highlighted practical applications, such as using Kafka to propagate changes across bounded contexts, ensuring eventual consistency while maintaining service autonomy. His demo showcased Kafka’s integration with microservices, illustrating its power in handling distributed data.
Leveraging Debezium for Data Synchronization
Christian also explored Debezium, an open-source platform for change data capture, to address historical data synchronization. He described how Debezium’s MySQL connector captures consistent snapshots and streams binlog changes to Kafka, enabling services to access past and present data. This approach, he noted, supports use cases where services need to synchronize from a specific point, such as “data from Monday.” Christian’s practical example demonstrated Debezium’s role in maintaining data integrity across distributed systems, reinforcing its value in microservices architectures.
Integrating Apache Camel for Robust Connectivity
Delving into connectivity, Christian showcased Apache Camel as a versatile integration framework for microservices. He explained how Camel facilitates communication between services by providing routing and transformation capabilities, complementing Kafka’s event streaming. Christian’s live demo illustrated Camel’s role in orchestrating data flows, ensuring seamless integration across heterogeneous systems. His experience as a committer on Camel underscored its reliability in building resilient microservices, particularly for enterprises transitioning from monolithic architectures.
Practical Implementation and Lessons Learned
Concluding, Christian presented a working example that tied together DDD, Kafka, Camel, and Debezium, demonstrating a cohesive microservices system. He emphasized the importance of explicit identity management, such as handling foreign keys across services, to maintain data integrity. Christian’s lessons, drawn from his work at Red Hat, highlighted the need for collaboration between developers and business stakeholders to refine domain models. His call to action encouraged attendees to explore these technologies and contribute to their open-source communities, fostering innovation in distributed systems.