Domain-Driven Design with Relational Databases Using Spring Data JDBC
ฝัง
- เผยแพร่เมื่อ 19 ต.ค. 2019
- Abstract: Domain-driven design introduces the concepts of Aggregate, AggregateRoot, and Repository. If one takes these concepts seriously, certain habits we picked up while fighting working with JPA become unacceptable. Even more, a substantial part of the complexity of JPA seems to become superfluous. The result will be performant, scalable, and maintainable.
A drawback of this approach is that we might have to fight our database administrator. But you can’t have it all, can you?
As it turns out, Spring Data JDBC supports this approach rather well.
In this talk, I’ll present how to design an object model the DDD way, why this might be a good idea, and how to build a persistence layer for it backed by Spring Data JDBC.
And I’ll even figuratively bring some candy to pacify the Database Admins.
Speakers: Jens Schauder, Staff Software Engineer, Pivotal
Filmed at SpringOne Platform 2019
SlideShare: www.slideshare.net/SpringCent... - วิทยาศาสตร์และเทคโนโลยี
Thank you for such an insight DDD is a must consider for every project
Awesome presentation! Thanks!
Thank you very much for this interesting video.
I think the problem with DDD is that it is often presented in abstract examples. A real example might be an invoice. The aggregate root is the invoice number. The invoice might involve tables for customer, line items and so on. However the business users will only talk about invoices and never about line items. It is implied that you should open and save whole invoices. However this is subjective in my opinion and is usually glossed over. Most accounting systems do present the invoice lines on a single screen, so it is not clear that you should not persist a single line, rathet than update a whole invoice. However "save invoice" is understandable to all (and is one way to ensure clarity). Then there are people, like me, that are not convinced that this simplifies anything.
DDD start at 25:01 :D
DDD blue book said repository is needed to focus on domain. Spring Data JDBC is more about CRUD rather than DDD's ubiquitous language. You cannot name methods as you wish, only by wrapping interface. Also, you forced to use all methods in standard interface, which you probably will never use. Some of them could be dangerous in domain, like findAll, or deleteAll.
So cool...
At least for me the naming of this cool stuff is somehow misleading. Probably not using word “JDBC” would be more intriguing the devs into this project.
Hello, I'm learning DDD and I have a question about aggregating entities on the DDD side vs normalization of tables on the RDBMS side and the relationship/tension between the two design goals in the different parts of the stack.
How is it the case that in RDBMS design, we want our tables to be normalized / split apart, and yet when we are representing entities in the Java code, we are forming aggregates, thus grouping those separated tables back together? It seems counterintuitive that on the DB side, we really want those tables split apart, but then on the Java side with DDD we are aggregating them. Especially counterintuitive is working with aggregates as a unit, all grouped together and effectively bound together? Wouldn't this imply that the normalized DB tables were split apart unnecessarily and those separate tables should be merged?
What am I missing in order to better understand why DB tables are normalized/split apart but DDD groups these things into an aggregate/unit?
Aggregates should be small and should only have references to other aggregates. You must ask if normalization is a domain concept or a technical concept. If you'd be using a non-relational database, like mongo, then you could store your aggregate as a single document/object.
I recommend you to watch Chris Richardson - th-cam.com/video/7kX3fs0pWwc/w-d-xo.html , much more informative actually.
I had the same question, and what if we are writing code on the already existing database schema.
Chapter 6, of the Domain Drive Design book (by Eric Evans); subtopic titled "Designing Objects for Relational Databases" starting on page 159 discusses some interesting points about this topic. I suggest you take a look at it.
can anyone share the source code? git link...
please share me repository
I’m tired of the relational model being compared to the “old” especially when you consider that many NoSQL solutions are based on concepts which are even older. Those general purpose RDBMs solutions are comparatively old, yes but many novel solutions based on the relational model exist too.
If you are watching, watch after 39:27.
There is plenty of great content before that as well.
Thanks for the hint, I was litterally getting bored
Modeling your Domain as DB Entity objects is the opposite of good DDD....
High-profile stuff was discussed in there, but MongoDB handles it all!
Maybe Spring Data Aggregate is better name than Spring Data JDBC
A complete waste of time. How about actually talking about the topic with a quick small demo project.
This presentation has nothing to do with DDD. Nothing useful here at all unfortunately.
It talks about Aggregates as a solution to the problems with JPA. Aggregates are a DDD pattern.
Yes but it also mentions that LegoModel is an (DDD) entity from DB perspective. Your Domain should never be coupled with DB. On one hand you have your Domain with Entities and Value objects and you can reason abou them depending on your domain/context. On the other hand there is your DB which is just a way of persisting them.
Half of the presentations are Meme. Horrible.
more and more really useless speeches found from pivotal members. What is going on over there? and omg if you not Josh Long - where is github link of your demo? can I quickly look for it not in blurry mode? cmn ....
DDD is stupid concept
I have been searching the stupid made it popular and which stupid use to say to design ddd is sufficient.
If any one know that gr8 guy let me know
Eric Evans
As boring as the sofa example!