Clone wiki

Java EE 6-Galleria / DomainModel

The Domain Model

The domain entities

The application contains 4 domain entities for now - User, Group, Album and Photo which are the same as the JPA entities in the logical data model.

For now, the business logic within the domain entities is primarily restricted to ensuring referential integrity. This may be improved even further, to incorporate the business logic involving various operations, into the domain objects. Such an improvement would require a few changes in the application; see the section on improving the application for more details.

The repositories

The application has 4 repositories - UserRepository, GroupRepository, AlbumRepository and PhotoRepository for each of the four domain entities.

Domain-driven-design requires that repositories be created for an aggregate root, and not for all domain entities. Although the User domain entity may appear to be an aggregate root, for the Album and Photo domain entities, necessitating the presence of the UserRepository alone, this is not the case. The domain entities may be requested, from the application layer (or even from the presentation layer). Therefore, a separate repository is created for each domain entity, without requiring the application or presentation layers to query for Albums and Photos via the UserRepository.

The repositories are created as Stateless Session Beans with a no-interface view. For now, the repositories are used only by the application layer, which is responsible for transaction management, thereby ensuring the presence of a transaction. The repository performs it's work in this transaction context.

The repositories are constructed using the Generic CRUD Service pattern published by Adam Bien, which is also quite similar to the Spring JPA CrudRepository.

The application layer

The application layer exposes services to be consumed by the presentation layer. It is also responsible for transaction management, while also serving as a fault barrier for the below layer(s). The application layer co-ordinates with the domain repositories and the domain objects to fulfill the desired objectives of the exposed services. In a way, this layer is the equivalent to a service layer in traditional applications, with the remote possibility that most of the responsibilities can be moved to the domain objects.

The application layer exposes it's services through the UserService, GroupService, AlbumService and PhotoService interfaces. To serve as a fault barrier, these interfaces throw instances of UserException, ModifyPasswordException, GroupException, AlbumException or PhotoException (which are ApplicationExceptions) when erroneous conditions are encountered. This also rolls back the effects of the current transaction when an error is encountered.

The application layer is also responsible for validating the providing domain objects from the above layers, before co-ordinating actions among objects in the domain layer. JSR-303 is used for validating the annotated constraints on the domain objects. Any violations encountered during validation, are wrapped into an Exception, that is thrown to the above layer to deal with. The violations do not contain the interpolated messages, since the application is meant to display localized messages. If interpolation were to occur here, the locale associated with the request context must also be passed to this layer. Not only does this violate separation of concerns (since localization is effectively a presentation concern), it is also a poor design choice (in my opinion) to pass presentation details (like Locales or RequestContexts) to downstream components to aid them in providing localized messages.