The Qlocky.UI application is running on customized Linux build.
The following diagram describes the Qlocky.UI boundary:
Qlocky.Ui Software Boundary
| Interface | Description |
|---|---|
| Environment Driver | Custom linux driver which is capable to communicate with Air Quality and Ambient illuminance sensor aswell control the ambient light. It combines all environment related sensors/actors in single driver. |
| Tap Driver | Custom linux driver which is capable to get acceleration data and processes it to get click/double click actions. |
| ALSA System | Linux internal audio system which is capable to play sounds. |
| Display & Touch Driver | External linux display and touch controller driver. |
| WiFi Driver | External linux driver for WiFi stack |
| Voice App | Future |
| Qlocky.Ai App | Future |
| Qlocky.Charger | Future |
While these architectural styles offer various advantages, they were not chosen for Qlocky.UI due to specific project requirements.
Layered (N-tier) Architecture: This style organizes the system into layers with distinct responsibilities, promoting separation of concerns. However, while the Layered Architecture offers this advantage, it can lead to tight coupling between layers and may lack the flexibility required for Qlocky's modular approach.
Microservices Architecture: This approach breaks down an application into small, independent services that can be developed, deployed, and scaled separately. While Microservices Architecture offers advantages in scalability and independent deployment, it also introduces added complexity in inter-service communication and management, which may be excessive for Qlocky's current needs.
Event-Driven Architecture: This style centers around the production, detection, consumption, and reaction to events, making it particularly useful for systems with complex event processing demands. However, while Event-Driven Architecture is well-suited for such scenarios, it may introduce unnecessary complexity for Qlocky's current needs.
Onion Architecture emphasizes the centrality of the domain model, placing it at the core of the application with layers of interfaces and services surrounding it. This style enhances maintainability and testability by minimizing dependencies on external layers. However, the strict adherence to the domain model can lead to rigidity in certain contexts, making it less adaptable to Qlocky.UI’s need for flexibility in module integration.
The chosen modular architecture strikes an optimal balance between flexibility, maintainability, and scalability, aligning perfectly with Qlocky.UI's specific needs and future growth potential. This approach offers several key benefits:
By adopting this architecture, Qlocky.UI can adapt more easily to changing requirements while maintaining a robust and efficient codebase.
The Qlocky.UI it’s decomposition is defined as following: