DDD & REST - Domain Driven APIs for the web - Oliver Gierke
Vložit
- čas přidán 27. 07. 2024
- Recorded at SpringOne Platform 2016.
Speaker: Oliver Gierke
Slides: www.slideshare.net/SpringCentr...
While Domain Driven Design is supposed to take care of complexity in the very core of software, REST is usually treated a plain remoting technology. In this talk we're going to explore some commonalities of the two when it comes to the design of both the domain and resources. We're going to discover how a good domain design is essential to build a great REST API in the first place and which means REST provides to make your APIs more domain driven. From all of the building blocks of DDD, the talk identifies the ones most important when it comes to building a good REST API: we're going to look at aggregates as natural boundaries for representations, repositories as the backing foundation for collection resources and how hypermedia allows to make domain specific state transitions explicit. - Věda a technologie
Amazing presentation, Oliver. 🇧🇷
Very helpful. Thank you so much.
Thanks a lot ... very helpful video ...
The book actually is called "REST in Practice" and it is by O'REILLY
18:28 can you please give some example how to extract model from database?
Great talk! Thanks
Now with java 21, you can code value objects with Java records ;)
Watching this damn late, god dammit, I love this talk.
If you know anything about DDD, watch from 30:00
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.
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
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
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.
@@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?
@@ITech2005 In that case it's an association and not an aggregate.
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.
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.
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 ?
Thanks
very methodically
Seriously good!
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
Because to get to 5th child I'd have to make 5 requests
Not really. Just request 5th child via ES or create explicit API for every member relationship /a/b/c/d/f
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.
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.
Amazing, thanks
great thanks
Really bad example of order status ((.
Cool
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.
Why is it whenever i watch a talk or research an unfamiliar technology, the language with the most issues regarding implementation, is always JAVA 😂.
Blablablabla
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.
You are pretty much coupled once you drink the spring boot koolaid
I also cannot believe that they talk about that in context of DDD.
Please stop taking the Lords name in vain.