mozaw39/breathbackend

Breath is a distributed application that consists of a backend logic developped with JEE specification and two clients(mobile and web), this repository contains the backend logic

Idea behind

"When emergencies occur, rapid medical treatment increases chances of survival exponentially. Using specially equipped motorcycle ambulances" United Hatzalah
This application helps people that have emergency situations call the nearest equiped motorcycle ambulance.

BreathBackend

Breath is a distributed application that consists of a backend logic developped with JEE specification and two clients(mobile and web), this repository contains the backend logic

Application architecture

I had the intention to build from scrash this application in order to experience some Design Paterns, and to help me get better into "clean code" and SOLID approaches, espacially when it comes to add new features and how to make your application extensible. "A minimun features modification/extension need to have a minimum code modification".
The main architecture model is based on Domain Driven Design using repositories to help persist/retrieve/update data in the database.

Modals

Modals used in this App:

Modals related to App users (roles/entities):

Urgencier: The person in charge of helping people in a emergency situation.
SimpleUser: The final user of the application (person in a emergency situation).
Candidat: Each person that want to become an "Urgencier" he must subscribe in order to join a training session, and if he passes the test he becomes an "Urgencier".
Admin: Person that handle accounts management, adding/removing/altering training sessions.
all of this modals inherite from a commun entity to help adapt the Domain Driven Design in a effectif way that is we only use a common Abstract class to handle all the common use cases.

Modals related to Business

Formation: each candidat(role) can subscribe to a "Formation" and after passing the test he can become an "Urgencier"

Repositories

AbstractRepo: This repo helps handle all the crud operation related to each entity, that helps using a clean DDD design and not repeating code in useless way.
RoleRepo: Each role has a specific repo that handle all the special operations.

Resources

The way how we handle App resources is that each Role use cases are build after a base URL named after the user role. i.e:
candidat resources: candidat/.... urgencier resources: urgencier/....

Authentication & authorization

Authentication and authorization are build using filters, each resource that demands authentication is put after the base url "/secured" (so that we intercept ony if a user reach secured resources).
to handle authorization: we handle autorization by testing the equality between the usertype (role) and the base url that he reaches. So we can say that the authorization part is handled at the execution level which make it a solid approach.