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

preview_player
Показать описание
Recorded at SpringOne Platform 2016.
Speaker: Oliver Gierke

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.
Рекомендации по теме
Комментарии
Автор

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

danyboomz
Автор

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

stgiaf
Автор

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.

leowilliams
Автор

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

andrzejpurtak
Автор

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.

heraldo
Автор

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 ?

dipanjanm
Автор

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

Lordrainor
Автор

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.

soumitripattnaik
Автор

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

testrad
Автор

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

mayuranchalia
Автор

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

sebastianszczebiot
Автор

Really bad example of order status ((.

Grynych
Автор

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

smaaktosuip_za
Автор

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.

Boss-grjw
Автор

Please stop taking the Lords name in vain.

TheNomadSoul