When working with devon4j the recommended approach for the design of the applications is the Component Oriented Design. Each component will represent a significant part (or feature) of our application related to CRUD operations. Internally, the components will be divided in three layers (service, logic, and dataaccess) and will communicate in two directions: service with database or, in the logic layer, a component with other component.
The benefits of dividing our application in components are:
-
Avoid redundant code.
-
Self contained, descriptive and stable component APIs.
-
Data consistency, a component is responsible for its data and changes to this data shall only happen via the component.
My Thai Star is an application of a restaurant that allows booking tables, and order different dishes so the main devon4j components are:
-
dishmanagement: This component will manage the dishes information retrieving it from the db and serving it to the client. It also could be used to create new menus.
-
bookingmanagement: Manages the booking part of the application. With this component the users (anonymous/logged in) can create new reservations or cancel an existing reservation. The users with waiter role can see all scheduled reservations.
-
ordermanagement: This component handles the process to order dishes (related to reservations). A user (as a host or as a guest) can create orders (that contain dishes) or cancel an existing one. The users with waiter role can see all ordered orders.
-
usermanagement: Takes care of the User Profile management, allowing to create and update the data profiles.
Apart from that components we will have other packages for the cross-cutting concerns:
-
general: is a package that stores the common elements or configurations of the app, like security, cxf services or object mapping configurations.
-
imagemanagement: in case of functionalities that will be used in several components, instead of duplicate the functionality (code) we can extract it to a component that the other components will consume. In the case of the images, as both dishmanagement and usermanagement components are going to need to manage images, this imagecomponent will be used for that purpose.
-
mailservice: with this service we will provide the functionality for sending email notifications. This is a shared service between different app components such as bookingmanagement or ordercomponent.
The component will be formed by one package for each one of the three layers that are defined by the devon4j architecture: service, logic and dataaccess.
-
Service Layer: will expose the REST api to exchange information with client applications.
-
Logic Layer: the layer in charge of hosting the business logic of the application.
-
Data Access Layer: the layer to communicate with the data base.
Apart from that the components will have a fourth package common.api to store the common elements that will be used by the different layers of the component. This is the place will contain common interfaces, constants, exceptions or enums.
As we mentioned earlier, each component will be related to a functionality and this functionality will be represented in code by an Entity that will define all the properties needed to wrap the logic of that feature.
This Entity, that represents the core of the component, will be located in the dataaccess.api package.
The naming convention in devon4j for these entities is
[Target]Entity
The 'Target' should match the name of the related table in the data base, although this is not mandatory.
Basically an Entity is simply a POJO that will be mapped to a table in the data base, and that reflects each table column with a suitable property.
