For each component of the application the logic layer defines a component facade.
This is an interface defining all business operations of the component.
It carries the name of the component («Component»
) and has an implementation named «Component»Impl
(see implementation).
The component facade interface defines the logic API of the component and has to be business oriented.
This means that all parameters and return types of all methods from this API have to be business transfer-objects, datatypes (String
, Integer
, MyCustomerNumber
, etc.), or collections of these.
The API may also only access objects of other business components listed in the (transitive) dependencies of the business-architecture.
Here is an example how such an API may look like:
public interface Bookingmanagement {
BookingEto findBooking(Long id);
BookingCto findBookingCto(Long id);
Page<BookingEto> findBookingEtos(BookingSearchCriteriaTo criteria);
void approveBooking(BookingEto booking);
}
The implementation of an interface from the logic layer (a component facade or a use-case) carries the name of that interface with the suffix Impl
and is annotated with @Named
.
An implementation typically needs access to the persistent data.
This is done by injecting the corresponding repository (or DAO).
According to data-sovereignty, only repositories of the same business component may be accessed directly.
For accessing data from other components the implementation has to use the corresponding API of the logic layer (the component facade). Further, it shall not expose persistent entities from the dataaccess layer and has to map them to transfer objects using the bean-mapper.
@Named
@Transactional
public class BookingmanagementImpl extends AbstractComponentFacade implements Bookingmanagement {
@Inject
private BookingRepository bookingRepository;
@Override
public BookingEto findBooking(Long id) {
LOG.debug("Get Booking with id {} from database.", id);
BookingEntity entity = this.bookingRepository.findOne(id);
return getBeanMapper().map(entity, BookingEto.class));
}
}
As you can see, entities (BookingEntity
) are mapped to corresponding ETOs (BookingEto
).
Further details about this can be found in bean-mapping.
For complex applications, the component facade consisting of many different methods. For better maintainability in such case it is recommended to split it into separate use-cases that are then only aggregated by the component facade.