Package petclinic

package petclinic
A re-creation of the Spring PetClinic Sample Application, using Java EE 7 for UI controllers and business classes. JMockit is used for integration testing, instead of the Spring Test Context.

Given the small size and simplicity of the application, it has minimal package structure. A larger real-world codebase should separate classes also in layers, rather than just in functional areas.

Using the architectural layers of DDD (Domain Driven Design), we could apply one of the two following structures: 

 petclinic
    owners
       application       (OwnerScreen)
       domain            (Owner, OwnerMaintenance)
    pets
       application       (PetScreen)
       domain            (Pet, PetType, PetMaintenance)
    vets
       application       (VetScreen)
       domain            (Vet, Specialty, VetMaintenance)
    visits
       application       (VisitScreen)
       domain            (Visit, VisitMaintenance)
    infrastructure
       persistence       (Database)
       domain            (BaseEntity, Person)
or 
 petclinic
    application
       owners            (OwnerScreen)
       pets              (PetScreen)
       vets              (VetScreen)
       visits            (VisitScreen)
    domain
       owners            (Owner, OwnerMaintenance)
       pets              (Pet, PetType, PetMaintenance)
       vets              (Vet, Specialty, VetMaintenance)
       visits            (Visit, VisitMaintenance)
    infrastructure
       persistence       (Database)
       domain            (BaseEntity, Person)
Either of the above is good, from the point of view of having cohesive packages. The package structure used in Spring's PetClinic is not a good one, because it groups together classes that are unrelated to each other, therefore violating the basic principle that packages should have high cohesion. For example, take the petclinic.web package: it holds both OwnerController and VetController, which are completely unrelated and independent of each other.