Introduce Aggregate Root, Entity, ValueObject, DomainEvent abstracts

[hantsy]

In Eric's DDD, a Repository is tightly tied with Aggregate Root, and used to maintain the lifecycle of a Aggregate Root. And a Aggregate Root could be consist of Entity, Value Objects, and can handle domain events. Have a look at jmolecules project: https://github.com/xmolecules/jmolecules/tree/main/jmolecules-ddd/src/main/java/org/jmolecules/ddd/types

In a JPA, it is easy to maintain the lifecycle like relation between PurchaseOrder and OrderItems, but switching to Jdbc(assume there is a data-jdbc module), it should apple changes to the whole Aggregate when calling a repository save/update etc.

[gavinking]

We discussed this issue quickly on the Jakarta Data call yesterday.

It's my opinion—and I believe that the others agree—that:

1. Jakarta Data 1.1 provides sufficiently-powerful primitives to express almost any DDD-style Repository that a user could possibly wish to write, but that
2. the specification itself should not directly encode particular patterns or ideologies which are embraced by only a small sliver of the Jakarta community.

The idea of "design patterns" is that they're patterns, not APIs.

On the call we agreed that this issue can now be closed.

[hantsy]

We can not avoid the patterns in the real world application development.

If we do not embrace the concept of DDD, here the Data Repository is just a DAO in the classic J2EE Design Patterns.

In an AggregateRoot, we hope can maintain the data easily in a root graph.

[gavinking]

We cannot avoid the patterns in the real world application development.

I mean, sure, but if a pattern cannot be implemented without a the use of a specific purpose-designed framework, then it's not a very good pattern.

If we do not embrace the concept of DDD, here the Data Repository is just a DAO in the classic J2EE Design Patterns.

OK, if you want to use the word "Repository" to mean "Repository in DDD", I can't stop you. I'm not going to use the word like that, but nothing requires us to agree on definitions of words.

So yes, concretely, I agree that "Repository" and "DAO" are in fact synonyms.

In an AggregateRoot, we hope can maintain the data easily in a root graph.

Nothing is stopping you from doing that.

But, just in case you're interested, here's an explanation as to why "aggregates" are a terrible idea when working with relational (as opposed to document or hierarchical) databases.

As I've pointed out many times: relational data is not made of trees, and so there are no "aggregate roots" in a relational database schema.

[gavinking]

Of course, @hantsy, if you can identify a concrete problem that makes it hard to implement the aggregate pattern using Jakarta Data, then please let us know what it is.

I assert that there is no such concrete problem, and that it's trivially easy to implement aggregates with Jakarta Data.

And I have the following very good reason for believing that: we know for sure that Jakarta Data works well with document databases, and so we can directly infer that it works just as well for someone who wants to simulate a document database using a relational database. And that's all the "aggregate" pattern is: it's an attempt to shoehorn a tree-like data model onto relational tables.