DDD & REST - Domain Driven APIs for the web

No video

DDD & REST - Domain Driven APIs for the web - Oliver Gierke

Рет қаралды 166,697

SpringDeveloper

Күн бұрын

Пікірлер: 41

@danyboomz 3 ай бұрын

Now with java 21, you can code value objects with Java records ;)

@raphasteps 3 жыл бұрын

Amazing presentation, Oliver. 🇧🇷

@leowilliams6848 6 жыл бұрын

I think this presentation missed the boat on the implementation of DDD in some respects, particularly the point of simplification. I stopped the video and read the 100 pages. However, when he said Entity + Repository = Aggregate, he completely lost me. The definition of an Aggregate is a group of associated objects which are considered as one unit with regard to data changes. A Repository does not change. It is a vehicle for change. The repository, based on my reading is not a part of the aggregate. It is an infrastructure instrument the aggregate interacts with. I could be dead wrong, but that was my takeaway from the reading. Also, the sub-classing of string I don't think adds clarification to the code. It actually does the opposite. As a developer, how can you tell what class the attribute is derived from, without digging further into the code? I think as developers we are tempted to over-complicate things that aren't truly complicated, as if it somehow adds a magic or degree of prestige to what we are doing. My takeaway from DDD is that the objective of tackling complexity in the heart of software is to reduce it as much as possible to something that is universally understandable within a given context, not shift, or add to complexity within a context.

@georgeFulgeanu 6 жыл бұрын

That Entity+Repository it's really not an aggregate, missed the point a little there. Spring people tend to implement any architectural pattern that really fits correctly. so many ideas in ddd are nice, maybe one or two of them are a bit of an overkill

@NiekVervaeke 6 жыл бұрын

I think he just meant to say that when you see an entity which also has a repository for it, then that entity is an Aggregate. This is because aggregates are the only things that you create repositories for, because all actions should be performed on the aggregates. Aggregate is read / adjusted / saved as a whole and consistency is maintained. Aggregates are in essence also entities. They are just the root entity. In his example you would have an Order aggregate (root entity) which contains a set of LineItem entities but you would only have an OrderRepository, not an LineItemRepository. This is also how it is explained in the book Implementing Domain Driven Design

@ITech2005 4 жыл бұрын

You're thinking about aggregates from a DDD perspective. Entity and Repository are functional aggregates. For example, an abstract Entity class with a dependency on the Repository.

@heraldo623 4 жыл бұрын

@@NiekVervaeke I thought Entites where the building blocks of the domain model. By domain model I mean the things that exists even when the application does not exists. Domain is a term used to decouple bussiness rules from the application, from the mechanisms that are emplyed to enforce those rules. We have always Costumers and Orders, so they belong to the Domain. But we need a mechanism to make this domain work (how to process that orders, how to record that data...), here comes the Application. I could have a business that does not employ computers, all processes could be managed throught paper notes. My repository could be a paper pile or a digital database stored in a HDD, depends on the application. I know that the Repository could be simple an interface located in the Domain Model, you could employ dependency inversion to make the domain agnostic to the application. But does the repository concept belong to the Domain Model?

@sebastianm7556 4 жыл бұрын

@@ITech2005 In that case it's an association and not an aggregate.

@sohrabsheykhmohammadi1909 3 ай бұрын

Amazing, thanks

@stgiaf Жыл бұрын

The book actually is called "REST in Practice" and it is by O'REILLY

@andrzejpurtak6811 4 жыл бұрын

If you know anything about DDD, watch from 30:00

@heraldo623 4 жыл бұрын

I thought Entites where the building blocks of the domain model. By domain model I mean the things that exists even when the application does not exists. Domain is a term used to decouple bussiness rules from the application, from the mechanisms that are emplyed to enforce those rules. We have always Costumers and Orders, so they belong to the Domain. But we need a mechanism to make this domain work (how to process that orders, how to record that data...), here comes the Application. I could have a business that does not employ computers, all processes could be managed throught paper notes. My repository could be a paper pile or a digital database stored in a HDD, depends on the application. I know that the Repository could be simple an interface located in the Domain Model, you could employ dependency inversion to make the domain agnostic to the application. But does the repository concept belong to the Domain Model? In Clean Architecture, Uncle Bob makes a clerly difference between Repositories and Entities, where repository is a concept that lives in the application, not in the domain model.

@TristanOnGoogle Жыл бұрын

in a DDD application, you may have at least 2 kind of "entities", domain entities used to form aggregates in the domain model and persistent entities (JPA entities for example) filled with persistence annotations and mapped on domain entities (and also mapped on tables in the database of course) . About repositories, u answer your own question imo : the definition of the repository (the interface) belongs to the domain. P.S. : it's a shame that the presentation is so abstract past the few first slides, a full code example would have been really useful.

@Lordrainor 7 жыл бұрын

Watching this damn late, god dammit, I love this talk.

@dipanjanm 11 ай бұрын

On HATEOS it reduces coupling between client and server but doesn't it increase chattiness between them because now the client has to call the service for reflecting every small change in them ?

@Lahiru_Udana 3 жыл бұрын

Very helpful. Thank you so much.

@1testrad 3 жыл бұрын

Thanks a lot ... very helpful video ...

@denniszhang2147 7 жыл бұрын

Great talk! Thanks

@sebastianszczebiot345 3 жыл бұрын

18:28 can you please give some example how to extract model from database?

@mayuranchalia 7 жыл бұрын

why would you add whole object as member of another object , rather than just holding a id reference...then you are solving Jackson serialization issue

@piddubetskyy 7 жыл бұрын

Because to get to 5th child I'd have to make 5 requests

@kanthPL 7 жыл бұрын

Not really. Just request 5th child via ES or create explicit API for every member relationship /a/b/c/d/f

@PatrickCornelien 7 жыл бұрын

of course, but usually JPA based systems have relationships modeled as properties and thus jackson would try to fetch them. Oliver didn't say that this would be the case if you use IDs instead of relationships, but then you also loose some benefits from JPA.

@leowilliams6848 6 жыл бұрын

I think this presentation missed the boat on the implementation of DDD in some respects, particularly the point of simplification. I stopped the video and read the 100 pages. However, when he said Entity + Repository = Aggregate, he completely lost me. The repository, based on my reading is not a part of the aggregate. It is an infrastructure instrument the aggregate interacts with. I could be dead wrong, but that was my takeaway from the reading. Also, the sub-classing of string I don't think adds clarification to the code. It actually does the opposite. As a developer, how can you tell what class the attributes are derived from? DDD is supposed to simplify code, not add complexity. We're tacking complexity at the heart of software, not contributing to it. What if you have 100 attributes. Do we create a class that subclasses string 100 times. I don't think this is a prudent approach, if that is indeed what he is doing.

@wernervogt2610 7 жыл бұрын

very methodically

@mayboroda 7 жыл бұрын

Thanks

@saikrir 6 жыл бұрын

Seriously good!

@soumitripattnaik 4 жыл бұрын

For the people who are complaining about Spring Data Rest being horrible, you know whats even more horrible cigarettes, but companies still make them and people still buy them. Point being, Spring Data Rest is an optional add on which is not shoved down your throat, take it or leave it, don’t be a cry baby.

@VinyJones2 7 жыл бұрын

great thanks

@sinch5 2 жыл бұрын

Cool

@G0rynych 6 жыл бұрын

Really bad example of order status ((.

@smaaktosuip_za5531 3 жыл бұрын

Why is it whenever i watch a talk or research an unfamiliar technology, the language with the most issues regarding implementation, is always JAVA 😂.

@Boss-gr4jw 5 жыл бұрын

Spring Data REST is one one the worst frameworks ever build. Violates all the design principles and marries your application to the vendor every way possible.

@tofuyam7361 5 жыл бұрын

You are pretty much coupled once you drink the spring boot koolaid

@sztigirigi 2 жыл бұрын

I also cannot believe that they talk about that in context of DDD.