I'm building a simple trading platform as a Java application that involves a few domains: Accounting, Markets, Exchange, Settlements, to name a few. I've decided to implement all of these domains as a separates Java packages within a unified Java project.
For each entity in any domain, I want to define an @IdClass/@EmbeddedId annotated primary key class rather than a primitive entity identifier. This Java doc describes the requirements of a PK class, which I understand well enough, but I'm looking to understand best practices regarding package organization within the context of a JPA/Spring application.
Now, there are several entities that reference PKs of entities from different packages without referencing the entities themselves. (e.g. a Trade in the Exchange domain may hold reference an AccountPK in the Accounting domain as a value object.)
My question is: should each of these PK classes be defined in the same package as its respective entity? Or, should I have a new package that defines all of these PKs as value objects?
My aversion to the first option is honestly more along the lines of having
Entity.javaandEntityPK.javaclasses redundantly cluttering the same directory. I've thought about defining the PKs as inner classes to avoid this, but that would seem to violate common wisdom about inner classes being used exclusively by the wrapping class.The obvious drawback to the second option is that every domain/package will now depend on this
PrimaryKeyValueObjectspackage, which is nothing but a bunch of PK classes that point to one another.
So I'm leaning more toward the first, but curious what others think!