Domain Driven Design: Entities, Value Objects, Aggregates and Roots with JPA (Part 2)

by simbo1905

Detour: Why use  JPA in this demo?

For the purposes of this demo JPA is an officially supported part of the Java ecosystem and is a mature and well documented Java-to-relational mapping tool. Yes it has a number of quirks. If you fight it your probably going to loose (your mind). If you learn how to do the basics and don’t deviate from that it can be a used as a rapid application tool to support an agile TDD build on Java against a relational datbase.

Why is JPA not universally loved? I would say that it is not because JPA isn’t a serious bit of technology that has had a huge amount of investment in it. It is because of the famous object to relational impedance mis-match. Scala programmers will say that the problem is actually that mutable OO is a concept with many traps and limited utility making persisence hard but that is an entire topic in it’s own.

A lot of developers think that working with an RDBM isn’t at all agile. Yet you can have JPA create tables into an in-memory java database for Unit testing as you write the code. That is pretty agile. This demo code does exactly that. It is then only a matter of packaging and deploying a different configuration pointing your application at a beefy industrial database server. I worked on a few projects that ran into very few differences in behaviour between an in-memory Java RDBMS and the commercial database server. Why? 

Because SQL and JPA are both very mature and google usually has the answer to any differences between products. The agility of fast test turnaround on new customer logic with full test coverage of database access is a guaranteed to save you days of time. In my experience the gains more the justifies the efforts of setting things up to unit test against an in-memory database.

Also if there is any ugliness due to our use of JPA then we can use that to illustrate a point in this demo: that the database and its mapping is an implementation detail that should be hidden from code that uses our object model. So the ugliness isn’t exposed to users of the entities it is kept as an hidden implementation detail. The sample code does this by lumping each root entity into its own package with a minimal public API.

In the next post we will discuss that the demo project is a rich domain library, that is front-end agnostic, and that should not be shared between teams or projects.