[DDD Europe 2024] DDD on the frontend

Recording: https://www.youtube.com/watch?v=2D5qZKfZmuY

Due to the specificities of frontend applications, modeling the domain in this context has always been challenging. Ranging from generating aggregate ids and designing their lifecycles, to the need to represent invalid states, to context mapping when communicating with vendor APIs, there are a series of factors to be considered when modeling the domain. In this talk, I will show you these specificities and how to tackle everyday frontend complexities using canonical DDD concepts, designing new bounded contexts just for the frontend, while still embracing modern frontend approaches.

Transcript

1. DDD on the frontend @talyssonoc | @codeminer42 Theory and practice
2. Talysson Oliveira Software architect & Technical development manager at Codeminer42 @talyssonoc beacons.ai/talyssonoc
3. codeminer42.com @codeminer42
4. …
5. Example scenario: Project management tool
6. Project management tool - The app supports multiple Teams - A Team is a group of people that work together toward common goals - Each Team can have multiple Projects - A Project is a continuous or finite plan to achieve a goal - A user of the app can be Member of multiple Teams - Inside a Team, a Member can be a Participant of multiple Projects - A Project contains multiple Tasks: - Type: Features, Chores and Bugfixes - Status: Unplanned, Unstarted, Started, Finished, Accepted - …
7. Project management tool context map Shared kernel Customer/Supplier Tasks Teams & Projects D Identity & Access U
8. Discovering the frontend domain model
9. Check the mockups 💡
11. Talk to domain experts and the UX team
12. Board Columns Sprints Project velocity (can be simulated) Estimate A draft of a task ✏ … Not estimated
13. Board Velocity Simulated velocity Backlog sprints Current sprint Task draft Columns Change tasks positions Task position Priority
14. Trying to make some sense of the business rules - A Participant interacts with the Tasks through the Board - The Columns are divided according to the Status of the Tasks - The Backlog has Tasks that are Planned but not Accepted yet - The Project Velocity is calculated by the backend somehow - The Project Velocity is used to separate the Backlog into Sprints - It is possible to use a Simulated Velocity - …
15. Characteristics of the frontend - Not just visual rules and behaviors - Visual representations that implement and enforce business rules - It has its own particular concepts and business rules - It has its own Ubiquitous Language - It has its own domain model
16. The frontend belong to its own Bounded Context!
17. Project management tool context map Shared kernel Customer/Supplier Frontend Tasks Teams & Projects D Identity & Access U
18. Project management tool context map Shared kernel Customer/Supplier Board (Frontend) Tasks Teams & Projects D Identity & Access U
19. Project management tool context map Shared kernel Customer/Supplier Customer/Supplier Board (Frontend) D D Tasks Teams & Projects D U Identity & Access U U Partnership Customer/Supplier
20. Challenges
21. Ensuring the model integrity
22. Ensuring model integrity - The browser can't be relied on as the source of truth - Domain rules shared by frontend and server, when performed on the frontend, can't be automatically trusted by the server - Domain logic on the frontend is also a matter of UX - We can’t ignore those technical limitations - How do we ensure the integrity of the model then?
23. Example use case: Participant creates a new Task
24. Composition of the Task aggregate - ID: unique - Title: unique inside its Project - Description: optional - Type: Feature, Chore or Bugfix - Status: Unplanned, Unstarted, Started, Finished or Accepted - Requester and Assignee: - Both are Participants of the Project - Unplanned and Unstarted Tasks might not have an Assignee - Estimate: 1, 2, 3, 5 or 8, only Planned features can have an Estimate - Priority: the lower the value, the highest is the priority
25. "Participant creates a new Task" business rules - A Task should never be created in the Accepted status - The Participant who created it is the Requester - A Task is always created with the lowest priority
26. Form to create a new Task { A Task
27. Form to create a new Task { A Task (right?) Unique? ? ? Priority ID
28. Form to create a new Task { A Task (right?) Unique? ? ? Priority ID
29. Aggregate design on the frontend - Some invariants conform to models implemented on a server - Changes on those aggregates should not be trusted until validated - Special case: generating a new id on the browser - We can't trust that the generation algorithm is legit - Even if we use something like randomUUID(), it could be spoofed - These scenarios should be designed accordingly
30. Smells like an implicit concept that should be made explicit
31. Backend Task (Frontend) Form (Frontend) Represents Is sent to Creates the Task Responds with a Task Provides data for
32. Backend Task (Frontend) Form (Frontend) Represents Is sent to Creates the Task Responds with a Task Provides data for
33. Backend Task (Frontend) Form (Frontend) Represents Is sent to Creates the Task Responds with a Task Provides data for What is it then?
34. Board Velocity Simulated velocity Backlog sprints Current sprint Task draft Columns Change tasks positions Task position Priority
35. Task draft Board Velocity Simulated velocity Backlog sprints Current sprint Columns Change tasks positions Task position Priority
36. Task Draft (Frontend) Backend Task (Frontend) Form (Frontend) Represents Is sent to Creates a Task Responds with a Task Provides data for Permissive Aggregate Validated Aggregate
37. The Validated and the Permissive Aggregates - Frontend aggregates that conform to backend aggregates often need a permissive counterpart - This counterpart represents the intent to create an aggregate - We call this intent a Permissive Aggregate - The domain rules of the Permissive Aggregate are looser - After persisted by the server, we get a Validated Aggregate back - In this scenario: - The Permissive Aggregate only exists in the frontend model - The Validated Aggregate is a concept shared between frontend and backend
38. Permissive Aggregate Validated Aggregate Example implementation of Task and Draft in TypeScript
39. Invalid states
41. Frontend validation error
42. Frontend validation error Server validation error
43. Errors in the Permissive Aggregate - Model the Permissive Aggregate as something that support error states as part of its life cycle - This way, this part of the model will fit the frontend domain nicely - E.g.: - A Draft is still in the stage of elaboration, so it can contain errors - A PaymentAttempt may fail, for example, if the payment can't be completed - …
44. How to represent it in code?
46. Implementation guidelines - Prefer plain objects + functions instead of classes - Simplicity and flexibility - Matches the patterns of the community - Works better when we… - Use immutability - Works better when consumed by the UI and the state management layer - Use TypeScript - Make types and concepts explicit in the code - Collocate types and functions that operate on those types - Similar to how a class would force it to be
47. Holding invalid state - After a Validated Aggregate change, return a Permissive Aggregate - domainOperation(validated) = permissive - Have a function that tells everything that is invalid - Rely on backend validation only when trying to persist - Which leads us to…
48. Repositories
49. Repositories on the frontend - Frontend repository implementations interact with: - APIs (REST, GraphQL, …), the browser (LocalStorage, IndexedDB, …) - When persisting a Permissive Aggregate: - Perform a frontend validation first - If everything is fine, send the request, performing a backend validation - What we get back is a Validated Aggregate instance - Repositories are the place to assign this responsibility
51. Validated Aggregate
52. But…
53. APIs are (usually) way more restrictive than databases
55. Databases and repositories HTTP APIs and repositories POST /api/tasks/:id/start and PATCH /api/tasks/:id
56. Databases and repositories HTTP APIs and repositories POST /api/tasks/:id/start and PATCH /api/tasks/:id ?
57. A wrong repository implementation that just proxies the API
58. A wrong repository implementation that just proxies the API The repository should not be an API client
59. Interacting with restrictive APIs - When the relation with the API is a partnership or C/S, this is fine - It becomes a problem if you’re conforming to a external service - Two main scenarios: - More than one endpoint is needed to fetch an Aggregate - GET /api/projects/:id GET /api/projects/:id/settings - A different endpoint is used for different changes of the same Aggregate - POST /api/tasks/:id/start PATCH /api/tasks/:id
60. More than one endpoint to fetch an Aggregate 1. Check your model ‐ Is it actually a single Aggregate? - If it’s not, refine your model and design your code accordingly 2. Check the relation between the frontend BC and the API's - Can the API be changed to accommodate the needs of the frontend? 3. Maybe you will really need two requests - If one of the requests fails, can it be retried? - Are there safe fallbacks that won’t hurt the model integrity? 4. If nothing else can be done, it’s ok to throw an error
61. Different endpoint for each change of the Aggregate 1. Is it possible to infer the endpoint solely from the Aggregate data? ‐ If so, encapsulate it the Repository implementation 2. Is it possible to infer the endpoint knowing what changed? ‐ If so, we have two possibilities: a. Use Domain Events to track the changes b. Compare the Aggregate before the change with the new version 1. Keep a copy of every fetched data inside the Repository instance 2. Redux store, or the cache of the fetching library (e.g.: TanStack Query) ‐ Encapsulate it in the Repository implementation
62. How to implement it?
66. Accept when a repository is not the answer - If a repository effectively adds more complexity - Or just won’t fit nicely in your domain model… - Maybe a repository is not the answer for this scenario - Consider designing a “external” Application Service to encapsulate the access to the other bounded context. For example: - An interface: TasksService - An implementation: HttpTasksService
67. Context mapping
68. Context mapping - Most production-grade frontend applications depend on at least one backend - So context mapping is a constant when using DDD on the frontend - Most frontend bounded contexts are either: - In a Partnership relation - At the downstream side of any other type of relation
69. Project management tool context map Shared kernel Customer/Supplier Customer/Supplier Board (Frontend) D D Tasks Teams & Projects D U Identity & Access U U Partnership Customer/Supplier
70. Discover and implement - Discover what are the proper relations between the frontend and the other bounded contexts - Use repositories and application services to express these relations and the translations between the bounded contexts - Use the mapping to avoid the frontend from being corrupted by: - The API domain model, variable/attributes casing, HTTP status of the API, … - Take care not to implement every relation as if the frontend was always Conformist
72. Additional insights
73. - Plays the same role as they would in a model on the backend - Don't make the frontend be responsible for preserving a server domain model, move system-wide events to the server - If possible, use the same mechanism used by your repositories and services to track changes - E.g.: dispatch events as Redux actions after the persistence is confirmed - If a domain event needs to be translated into a system event, try to also use the same mechanism as the rest of the events - E.g.: if using Redux, use the Redux Toolkit's Listener API Domain events
74. - Backend use cases are usually transactional - But on the frontend, use cases are stateful - Try to reason about the frontend use cases as sagas or state machines: - Between each state, there is user interaction that generates events - The Permissive Aggregate is used as (part of) the state of the use case Stateful use cases
75. Task info is input "Create new Task" use case User clicks Save button The end. User clicks +Task button
76. Task info is input "Create new Task" use case User clicks Save button The end. User clicks +Task button
77. Task info is input "Create new Task" use case User clicks Save button The end. User clicks +Task button * Oversimplification
78. Example frontend use case implementation
79. Example adapter implementation for React
80. - Implement the use case logic isolated from the UI - Then adapt it to the UI making the lifecycle and established patterns of the UI technology as the engine of the use case flow - Eg.: - React + useState + custom hooks - Vue + Reactivity API - Flutter + BLoC - Leave reactivity and state management for the UI layer to implement Implementing use cases on the frontend
81. And then…
82. The rest is canonical knowledge - Some parts of your bounded context only exist on the frontend - Model and design these the way you would do for anything else - You don't need microfrontends to have multiple bounded contexts on the frontend just like you don't need microservices to have multiple bounded contexts on the backend - Of course DDD won’t ignore technical limitations - But it’s not a reason to think that DDD on the frontend is a completely different thing
83. Takeaways - Talk to domain experts and the UX team - Discover implicit concepts that should be made explicit - Don't be afraid of creating new domain concepts - Discover your domain model by separating UI behavior from visual implementations of domain rules - Protect domain code from technical limitations - But accept when technical limitations cannot be circumvented - Use canonical knowledge, but adapt when necessary
84. Thank you, DDD Europe! @talyssonoc | @codeminer42