DDD on the frontend - Talysson Oliveira Cassiano - DDD Europe
Вставка
- Опубліковано 1 жов 2024
- Domain-Driven Design Europe 2024 - Organised by Aardling (aardling.eu/)
dddeurope.com
newsletter.ddd...
/ ddd_eu
/ domain-driven-design-e...
Due to the specificities of frontend applications, modelling 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 modelling 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.
About Talysson Oliveira Cassiano:
Web developer and software architect, a true believer that we can always do better.
I'm glad to see people finally talking about how to make frontend code decently. For so long, we've been denying that and the price we pay for messy frontend code bases is so high that we promote them to legacy within 3 years, blame the UI framework, or tell our product team we gotta rewrite everything from scratch. It's never our fault!
I watched your last talk in JSConf Chile and I think you brought a much more concrete example this time, that suffices the real necessity of applying DDD concepts and clean arch in a project that is complex enough. It's also much clearer in terms of details like why considering the frontend a BC and why it's a matter of UX.
However, I did miss a link to a project where devs can play around and see how everything fits together. Great talk!
This is very interesting thanks for sharing
very nice! 👏
Don't waste your time. I feel like he's really very much conflating concepts together. There's no such thing as the "domain model of the frontend" and you really should not implement this type of logic on the frontend. The issue is that he's imagining an entity-based API with CRUD-y operations instead of domain-specific tasks. That can be things like create-draft, etc. And Backend-for-Frontend is a valid solution for a lot of the composition that might be required to present the UI, that doesn't mean you "have another bounded context". He's conflating all concepts together including the technical problems with the domain problems and so on. And a lot of his suggestions are just... meaningless without explanation. "If the repository is adding too much complexity, create a service." What??? Also, is he really recommending redux just to be able to diff the JSON objects, instead of just designing task-based UIs that are clear and doesn't require that we magically infer what the user is trying to do?
I completely agree with your point. It's essential to recognize that the frontend is an integral part of the application (Web-app/Mobile-app/Desktop-app, aka Presentation Layer) rather than the domain. Describing UX as a bounded context doesn't quite fit, as UX differs across platforms. Let's imagine for the moment that it is actually possible/makes sense - creating a separate bounded context for each platform could result in unnecessary duplication and inflated logic.
"Don't waste your time. I feel like he's really very much conflating concepts together. There's no such thing as the "domain model of the frontend" and you really should not implement this type of logic on the frontend".
With all due respect, this is just an opinion. Why implementing "this type of logic" on the frontend is not a thing? It really depends on the project, but you definitely can have logic on the frontend, especially when that logic only exists on the client side. He mentioned during the whole talk about not FULLY relying on the frontend and even made it explicit by coming up with an entity that represents that (permissive aggregate). It's all about ENFORCING what the backend will validate later to benefit UX.
"And Backend-for-Frontend is a valid solution for a lot of the composition that might be required to present the UI"
Did you miss the part where he says that domain logic on the FE is a matter of UX? So why dispatch a thousand requests when you can do it locally (on the frontend)? Why spend server resources with a BFF when you can use the client resources? Not enough? Why if your app need to work offline?
Complexity definitely exists on the frontend, unless you just have to develop a simple CRUD app.
Regarding his suggestions, I agree with you it's a bit confusing. But it's a workaround/adaptation for potential limitations between your FE domain and external providers.
@@ggbelgamo I think although I agree with nearly everything you said, I disagree that these concerns of better UX, offline-first, etc. are what makes up a "bounded context" in the sense that he talks about it in the presentation. And yes, I understand there are many use cases that requires that logic is implemented on the frontend or duplicated (eg. I have implemented collaborative forms and almost all of the logic related to conflict resolution, undo/redo, etc. was entirely on the frontend and the backend only really starts to care after you actually click save or submit). But you still have to keep in mind who ultimately owns the data, who enforces the business rules, and so on. And the frontend simply can't own the data, can't be relied on to enforce rules, and can't guarantee anything about the data, can't design its API. It is by design only able to participate as a client to interact with your context (with exceptions ofcourse, like browser games, etc.).
And when I say "this type of logic shouldn't exist on the frontend", I am more-so trying to say you should not do things like trying to infer a user's intent using redux (discussed around 29:30) instead of exposing a task-based API with clear intent, or trying to infer what the user has permissions for based on user role, for example. Instead, the API that provides you with the task data, should also include the actions that you are able to take on that task. This means the client shouldn't be the one enforcing the rules described at 9:30 (eg. you can only assign estimates to Planned tasks), and instead, the API should be very explicit about whether you can or can't assign an estimate to a task. Because you might change that rule down the line, and ideally you shouldn't have to also change that logic on the frontend. I didn't mean to say that the client needs to keep making useless requests, I just mean that the API should be designed in a way that explicitly avoids any ambiguity to begin with. It should return the data that the frontend needs for its UI/UX, and the frontend shouldn't be required to infer endpoints and user intent (eg. At 33:55 he tries to infer user action, and based on that has to make calls to different endpoints and publishing events based on that).
Sorry for the wall of text here I appreciated your thoughtful response and tried to do the same.
Thanks for the positive feedback, have a good day
I would say the concepts discussed are quite polemic and controversial but i have lots of respect for those ones that are early adopters and have enough power to go public and show his ideas openly without being so concerned of what even fellows will think of.. Maybe a bit ahead, maybe not, but for sure triggered in our minds a question if this is a good approach or not.
The frontend is part of the Presentation Layer and should not be treated as part of the Domain or considered a bounded context.