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

This is the last article in the series which discusses a sample app that does DDD using JPA. I would hesitate to recommend using JPA for DDD unless you are very familiar with JPA. Why? Some of the issues you can hit using JPA are written up on the Scabl blog on Advanced Enterprise DDD. In my own code and this blog, I explained how to dodge some of the bullets, but you need to be quite aware of the pitfalls of JPA to dodge them all. So why did I write the code?

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

Don’t abuse the `public` keyword in Java. The demo source code has very few public classes or methods. This is unusual for Java projects. Typically Java projects have package layouts that model the solution; “this package has all the entities, that package has all database related code, that package is all the services code.” That approach forces you to make almost everything public. There is no way the compiler can enforce boundaries that align to the business domain. In the long term, on a big project, many brittle connections will be made across business responsibility boundaries. Bit rot creeps into the design and your application becomes a big ball of mud. You should Tell Don’t Ask across domain boundaries in your application and align your package structure to the to the domains of your application and not any technical layers. 

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

Where’s the application in the demo code? There isn’t one.

If you look at the source code there is no front-end, no web servlets, no screens, and no Java main class, and so no way to run it as an application. All that you can do is run the test class. So it is a library project. It is a rich “back-end” that can talk to a database. In this post, I will recommend that you don’t share such a library project between multiple teams. 

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

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 quite a few quirks. If you fight it you will probably lose (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 database.

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

A friend with a relational database background was working on an OO domain modeling problem. I started talking about “aggregates” and “roots” and things like “make the contract entity an aggregate controlling the other entities” and that “external logic should speak to the object model via a few root entities.” So I wrote demo project is some Spring and JPA code in Java to demonstrate those concepts. This blog series will be some discussion around the design and implementation techniques.