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.

So cool...

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.

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

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?

@darkr0astedblend

3 жыл бұрын

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.

@UTUBDZ

3 жыл бұрын

I recommend you to watch Chris Richardson - kzread.info/dash/bejne/aZ-MlcisYNO9p8Y.html , much more informative actually.

@gauravpolekar2158

2 жыл бұрын

I had the same question, and what if we are writing code on the already existing database schema.

@salmanmohammed8894

2 жыл бұрын

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.

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.

please share me repository

If you are watching, watch after 39:27.

@szelpe

4 жыл бұрын

There is plenty of great content before that as well.

@yapadqoi

3 жыл бұрын

Thanks for the hint, I was litterally getting bored

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.

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.

Half of the presentations are Meme. Horrible.

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

@VictorMartinez-zf6dt

3 жыл бұрын

It talks about Aggregates as a solution to the problems with JPA. Aggregates are a DDD pattern.

@milosbiljanovic6343

11 ай бұрын

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.

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

@koustubhmokashi4047

10 ай бұрын

Eric Evans

As boring as the sofa example!