-
Notifications
You must be signed in to change notification settings - Fork 3
04. Solution Strategy
First: for this little app the internal 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.
As I won't invest on expensive cloud structure at the beginning I chose a modern old school approach: Taking in by raspberry-pis as a home-made on premise computational center ;-)
The internal structure is mainly build upon JPA data repositories and a business-layer (aka service-layer) on top of it. A good introduction about it can be found e.g.: here
Expected to use the REST api, but maybe I intend 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.
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, while working internally with JPA repositories, to access the PersistenceLayer.
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.
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.
For language detection we take the users preferences with english as fallback.
For those cases we work with resource-bundles. This eases the introduction of a new supported translation.
Some content like the fish catalogue will be stored in some multiple language.
We are using JPA managed Entities in combination with Spring-Data Repositories. The Repositories 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.
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.