Crafting Domain-Driven Designed REST APIs - Julien Topçu - DDD Europe 2022

Подписаться 30 тыс.

Просмотров 14 тыс.

50% 1

Domain-Driven Design Europe 2022
dddeurope.com - / ddd_eu - newsletter.dddeurope.com/ / domain-driven-design-e...
Organised by Aardling (aardling.eu/)
You have just coded your business logic by applying the principles of Domain-Driven Design! But when comes the time to write your API, you are facing a serious issue! All the intention and the expression of your domain go up in smoke to fit the blankness methods GET, POST, etc.
Denatured by the REST layer, the business workflow is then deported on the consumer side to compensate for the limited vocabulary of this well-known CRUD protocol...
During this talk, we will see how to bring the business intent back inside the REST API by finally being able to expose our domain services and agregates' methods. The business workflow will also be encapsulated in the REST API in order to have the power to guide our consumers through the workflow of our domain.
About Julien Topçu
I like to craft software with high business value using techniques from Domain-Driven Design, all powered by Xtreme Programming in the Kanban #NoEstimates philosophy. Member of the OWASP foundation, I evangelise on application security techniques in order to avoid being hacked properly.

Наука

Опубликовано:

28 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 21

@AvineshSinghSaab 11 месяцев назад

Despite the specific title, there is so much to learn from this talk that I have re-watched it thrice. Beautifully explained, love the energy and very practical!

@alexdorand Год назад

beautiful talk with an amazing start.

@DevOpsCraftsman Год назад

Very interesting talk! I think that lot of advises are pretty actionable quickly on most projects. Digression: I'm very frightened by the state of the audience... I'm feeling that DDD is getting so mainstream that people are coming to talks just because it's "fashion" theses days to go to a DDD conf.

@corlaez 5 месяцев назад

on the flip side they may be trying to learn and change. I would look at it with a little more hope. Sadly there is information loss on esch generation, it is inevitable, I would be more worried if the audience was full of experts, at that point ddd is no longer growing.

@nichtverstehen2045 9 дней назад

well, basically, all we need is to go back to server-rendered content and forget about that rich-client crap. i totally agree with that. front-end should be simply about the look. functionality must be handled in single place - the back-end. simplicity is the ultimate sophistication -- leonardo da vinci

@farewelltitet Год назад

Thanks you, this is a very interesting talk. I'm not familiar with hateoas, how about the request which perform an action that need a large body, we can't put it in url, as usual we make a post request with a json body.

@corlaez 5 месяцев назад

The htmx essays are a great way to learn about hateoas. This concept is defined in Roy Fielding's Rest Architecture paper and it describe how the web works. as such tou aren't limited to the url. you can use headers and the body. A form can serialize a big request in the body. There is form encoding, besides the json that is common. i recommend you check out htmx and learn why html is the best way to implement hateoas

@corlaez 5 месяцев назад

htmx essays are the best place to learn about hateoas. They (and I agree) will advocate gor using html in the response and not json. forms will encode data into a the request (on the body in post and on the queryParams in get)

@smithdragon6477 Год назад

so we don’t need pass post body as json? If we need pass body as json how do we return it through links

@corlaez 5 месяцев назад

forms with a post method are the native way to tell the browser you want to encode a bunch of fields and send them in the request body when submited to the server. for more on hateoas and to learn the best way (and the right times) when to use it, i recomend you read the essays on htmx

@corlaez 5 месяцев назад

htmx essays are the best place to learn about hateoas. They (and I agree) will advocate gor using html in the response and not json

@varshard0 2 месяца назад

@@corlaezif the API is used by a mobile app also, how does that work? Do mobile clients parse the HTML response and traverse the xml tree?

@BeekuBird 8 дней назад

REST uniform interface isn't the same as CRUD.

@chauchau0825 8 месяцев назад

IMHO, he is right on the problems but wrong on the solutions

@kamilszymanski1426 8 месяцев назад

You could give some examples of the right solutions to make your comment constructive :)

@chauchau0825 8 месяцев назад

Not my responsibility but ok. 2 quick comments and I'm done. 1) The whole talk leads to one thing: HATEOAS - a useless overengineering model brings unnecessay complexities causing you to constantly fighting the tool to solve a problem that doesn't even exist 2) slightly brought up DDD as a buzzword but didn't have any compelling explaination. Also what's the point of talking about Domain Model when everything he touched on is still happening in the User Interface layer? A simple rule of thumb to save anyone time to watch the whole talk could be: Use Task based REST API instead. Only use resource based REST API when you are doing CRUD operations of a dead simple model e.g. updating a small internal config record in db

@kamilszymanski1426 8 месяцев назад

@@chauchau0825 Well you said "IMHO", so it's no one else responsibility to explain what did you mean I think. Personally I kind of agree with what you said about HATEOAS. Tried couple of time to implement it, but in the very end didn't find a very good reason to follow it further and in fact we were dropping that idea (especially the complexity/maintenance tradeoff). However after this talk I have the impression we didn't see the value, because the idea was dropped too fast. Gonna give it another try I think. Yes DDD is like a buzzword this days. However as I understood (also the title says that) he didn't want to showcase Domain modeling, but just how to build an API expressed a kind of domain way. In fact he managed to do it and I wouldn't say he has used DDD just to gather more attention. Thanks for sharing your thoughts, now it's constructive criticism 👍.

@chauchau0825 8 месяцев назад

@@kamilszymanski1426 apologies for being rude if hat makes you unhappy. The industry has rejected it. Bare no one is talking about it. Rarely anyone is using it. But every now and then, someone jumps out and advocates about it. "See you don't understand it", "I understand it", "I know how it works", "Do it my way and it will work". [Trigger warning and nothing personally] HATEOAS is like communism. Where it applies, it always failed and caused disaster. But there are always someone foolish enough to think they out smart everyone else and keep trying it. Millions of people died due to communism and millions budgets wasted due to HATEOAS. The industry rejected HATEOAS not because no one understand it, but the exact opposite: understanding how dumb it is. IMO, He didn't managed to build an DDD REST API. What he said is basically saying, in my own way to summarize his words, "use a separate endpoint for different action". There is nothing in talk about DDD. I do think he did used DDD just to gather more attention.

@corlaez 5 месяцев назад

ddd does seem like a stretch, i guess it was a way to make the talk more appealing to the conference. I wonder if you guys that have had bad experiences with Hateoas tried to implement it via json. I have found that using html (specially enhancing it with htmx attributes and related js library) provides a simple way to provide hateoas interfaces for humans. So I do agree with the hateoas solution.