Domain-Driven Design with Relational Databases Using Spring Data JDBC

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

[cypcode]

Thank you for such an insight DDD is a must consider for every project

[seb]

Thank you very much for this interesting video.

[robertwhite]

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.

[feoktant]

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.

[ebichu]

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.

[amjadkarim]

can anyone share the source code? git link...

[georgepantazes]

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?

[hiamitchaurasia]

If you are watching, watch after 39:27.

[genericperson]

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.

[tosho_ait]

Modeling your Domain as DB Entity objects is the opposite of good DDD....

[atataheri]

High-profile stuff was discussed in there, but MongoDB handles it all!

[geonhyeokgo]

Maybe Spring Data Aggregate is better name than Spring Data JDBC

[olegvorkunov]

Half of the presentations are Meme. Horrible.

[faisaladil]

A complete waste of time. How about actually talking about the topic with a quick small demo project.

[Boss-grjw]

This presentation has nothing to do with DDD. Nothing useful here at all unfortunately.

[vibedistortion]

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 ....

[kisan-majdoorkalyansamiti]

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