Domain Driven Design with relational Databases.
The ORM disaster.
Entity == Table.
Property == Column.
What about references?
Lazy loading?
Eager loading?
JPA offers both!
What about persisting/deleting?
(Optimistic) Locking?
How about testing?
The solution comes from 2004.
Actually it’s from the 1990s!
Aggregates.
An AGGREGATE is a cluster of associated objects that we treat as a unit.
Domain-Driven Design
— Eric Evans
— Eric Evans
Aggregate Root.
Aggregates are Boundaries of integrity
Transactional consistency inside
Eventual consistency between aggregates
How to represent this in Java?
Annotations!!!!
No References Across Aggregates
It makes life much easier if you just keep a reference of the aggregate’s ID rather than the actual aggregate itself.
— David Masters
It cuts down complexity
What to load/persist/delete?
Everything within an aggregate.
Optimistic locking of collections?
Lock on the aggregate root.
How about testing?
Nobody cares if the entity referenced by an id exists.
No M:1 or M:N
except via IDs
But, but the Foreign Keys!
Separate data store.
Deferred constraints.
Normal Foreign Key Constraints.
Wrap up
Model aggregate boundaries in the domain model.
Reconsider where you want foreign keys.
Time left for Data JDBC?
Spring Data implements repositories.
Spring Data JDBC follows the described model.
Persistence via JDBC.
Everything referenced gets persisted.
Code.
Resources.
Vaughn Vernon
Spring Data JDBC
DDD vs JPA
Ted Neward
Jens Schauder
Dad, Board&Roleplaying Gamer, Runner, Bouldering, Freeletics Masochist
+
JUG Organizer
