-
Notifications
You must be signed in to change notification settings - Fork 3
04. Solution Strategy
First of all: for this little app the architecture is overblown for sure. However I would like to make it (almost) right at the beginning and liked the idea to have a small blueprint at hand with it, to ease further projects.
The internal structure is build upon DAOs and ServiceLayer. A good introduction about it can be found e.g.: here
Expected to use the REST api, but maybe I intent to offer other interfaces too. The design need to ease these extensions in the future.
This is where the client is talking to. For the REST clients it's all kept in de.bluewhale.sabi.rest package. (html endpoint is planed, too)
Business logic like (validations, business rules, authentication, authorisation, BI and reporting stuff) that is shared by the different client technologies is being kept in here: de.bluewhale.sabi.services Though in the beginning all is running on one server, this design eases infrastructure refactorings, if we want to have the Client API endpoints on multiple "frontend" servers, which will communicate to the (multiple) backend servers. If this business domain is growing we might introduce a domain cut, where each domain might run on different servers.
The ServiceLayer exposes only TransportObjects through the interfaces. Entities will be used only within the ServiceLayer.
In case of (business) failures we will introduce a common BusinessException which contains the different reasons as messages, which will be used to signal errors to the API-Endpoints which in turn have the responsibility to translate and deliver them back to the client.
The API Layer (in case of validation messages) or the client (lables etc.) himself is responsible to do all the translations. Thinking of typical frontend backend machine scenario, I want to keep the traffic between those machines as small as possible, as transferring all possible translations to the webserver which in turn delivers one to a specific client won't do it.
Some content like the fish catalogue will be stored in some multiple language. For access the users preferences will be taken (with english as fallback).
We are using JPA managed Entities in combination with DAOs. The DAOs are used as repositories, which are responsible to manage all CRUD and other persistence operations. The intention of this layer is to isolate the application logic from the persistence layer, through which we are allowed to do persistence refactorings (e.g. for performance sake) without mingling with the object models used on the client site. Or in other words, we are able to evolve data and application layer independently. So all DAOs will never return an entity, but TransportObjects. As the transport objects are part of the application model and therefore required by the server and maybe the API Endpoints as well, you will find them in de.bluewhale.sabi.model of the sabi-boundary module.
Our persistence layer is being kept in de.bluewhale.sabi.persistence of the sabi-server module.
In case you want to know: All diagrams were generated with plantuml. The diagrams source code has been checked in, just have a look into the sabi-server/UML directory.