[JSConf Chile 2023] How do DDD and software architecture play on the frontend

1. How do Domain-Driven Design and software architecture play on the frontend?
2. @talyssonoc Brazilian codeminer42.com Glad to be here Talysson
3. What is the "domain"? “The sphere of knowledge and activity around which the application logic revolves” Source: <https://blog.airbrake.io/blog/software-design/domain-driven-design>
4. What is Domain-Driven Design? - DDD is a software design practice focused on the domain - The domain is described through a model cultivated by the developers in collaboration with the domain experts - Model as in "model aircraft" - DDD practitioners prefer to use architectures that are centered on the domain
5. What is software architecture? - It’s hard to define… but let’s give it a shot - How the components of a system interact and have assigned responsibilities prioritizing its success factors - It is not file organization - So, in a nutshell… - The team high level understanding of how the system works - Every system has an architecture, it’s better if it’s intentional
6. User interface Application (use cases) Domain (business logic) Infrastructure Layers of responsibility in an architecture UI frameworks, styling, I18n, formatters, …
7. User interface Application (use cases) Domain (business logic) Infrastructure Domain layer
8. "Make illegal states unrepresentable" Source: <https://blog.janestreet.com/effective-ml-revisited/> Entities, Value Objects, Aggregates, Invariants and Repositories*
9. Example: Diary application - The Diary is composed of entries - An Entry (an aggregate) is composed of: - ID: a number - Title: longer than 5 characters - Content: longer than 60 characters - Date: current or in the past
10. How do we create a valid Entry without an ID?
11. Illegal state
12. "Make implicit concepts explicit" How does DDD handle this? Is it really an Entry? Or is it… the intent to create/edit an Entry? Make the intent explicit
14. A new domain concept only for the frontend?! The frontend is a Bounded Context itself ⚠ Domain logic on the frontend is a matter of UX And it fits really well with…
15. * Repositories Responsible for abstracting persistence Their interface belongs to the domain!
16. User interface Application (use cases) Domain (business logic) Infrastructure Infrastructure layer
17. “Provides technical capabilities that support the higher layers” Examples: - interaction with APIs (REST, GraphQL, WebSockets) - interaction with the browser (cookies, LocalStorage)
18. Not an API abstraction
19. Repository implementations Respect the rules determined by the domain Abstract technical details
20. Actual API abstraction * Error handling omitted for brevity
21. User interface Application (use cases) Domain (business logic) Infrastructure Application layer
22. What are use cases? "[...] All the ways of using a system to achieve a particular goal for a particular user" Source: <https://www.ivarjacobson.com/publications/white-papers/use-case-20-e-book>
23. What make use cases on the frontend different? On backend applications, use cases (aka interactors) are mostly transactional On the frontend (and mobile, and desktop, …) use cases are stateful But transactional use cases are the exception
24. Example: “Create entry” use case - User clicks the "New entry" button - User edits the new entry data - The title can be edited (state) - The content can be edited (state) - The date can be edited (state) - User finishes it clicking the "Add" button
25. Mutability No reactivity from changes
26. How to keep the application layer stateful, reactive, and decoupled from the UI layer? By extracting the state from the use case Making the use case immutable
27. Injected state management Immutability Isolated state initialisation
28. Plugging it in into the UI layer (An example with React hooks) Leave reactivity and state management to the UI layer to implement
29. User interface Application (use cases) Domain (business logic) Infrastructure What about global state management?
30. Global state management: the layer #5 User interface Application (use cases) Domain (business logic) Infrastructure State management and server cache Provides data Updates the state after application events
31. Updating global state after application events State updates are triggered as consequences, not being actively requested by the UI Similar to backend event-driven architectures
32. User interface Application Global state management Requests data and subscribe to changes Notify changes Instruction Event
34. Toolkit
36. Architecture layers of frontend applications User interface Application (use cases) Domain (business logic) Infrastructure Provides data State management and server cache Updates the state after application events
37. Final considerations - There is a lot "canonical" programming knowledge out there that applies (or can be adapted) to the frontend, use it! - DDD and layered architecture - Dependency injection (aka DI) - Service-oriented architecture - CQRS and event sourcing - Use architecture to isolate complexity - Be patient, it'll pay off
38. Example - Diary application github.com/talyssonoc/frontend-architecture-jsconf-chile-2023
39. ¡Gracias! @talyssonoc beacons.ai/talyssonoc codeminer42.com
40. References and additional content - Making architecture matter <https://www.youtube.com/watch?v=DngAZyWMGR0> - Why We Need Architects (and Architecture) on Agile Projects <https://www.youtube.com/watch?v=Oyt4Ru7Xzq0> - Domain-Driven Design Reference <https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf> - Domain-Driven Design books <https://www.dddcommunity.org/books/> - Scalable Frontend #1 - Architecture <https://blog.codeminer42.com/scalable-frontend-1-architecture-9b80a16b8ec7/> - Dependency Injection is JS/TS https://blog.codeminer42.com/dependency-injection-in-js-ts-part-1/