This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Data Relational 3.3.5! |
Domain Driven Design and Relational Databases
All Spring Data modules are inspired by the concepts of “repository”, “aggregate”, and “aggregate root” from Domain Driven Design. These are possibly even more important for Spring Data JDBC, because they are, to some extent, contrary to normal practice when working with relational databases.
An aggregate is a group of entities that is guaranteed to be consistent between atomic changes to it.
A classic example is an Order
with OrderItems
.
A property on Order
(for example, numberOfItems
is consistent with the actual number of OrderItems
) remains consistent as changes are made.
References across aggregates are not guaranteed to be consistent at all times. They are guaranteed to become consistent eventually.
Each aggregate has exactly one aggregate root, which is one of the entities of the aggregate. The aggregate gets manipulated only through methods on that aggregate root. These are the atomic changes mentioned earlier.
A repository is an abstraction over a persistent store that looks like a collection of all the aggregates of a certain type.
For Spring Data in general, this means you want to have one Repository
per aggregate root.
In addition, for Spring Data JDBC this means that all entities reachable from an aggregate root are considered to be part of that aggregate root.
Spring Data JDBC assumes that only the aggregate has a foreign key to a table storing non-root entities of the aggregate and no other entity points toward non-root entities.
In the current implementation, entities referenced from an aggregate root are deleted and recreated by Spring Data JDBC. |
You can overwrite the repository methods with implementations that match your style of working and designing your database.