In the world of backend software development, the architecture you choose can greatly impact the flexibility, scalability, and usability of your applications. One such practical and efficient architecture is the modular layered architecture. The modular layered architecture breaks down an application into separate modules - each with specific functions. The higher level of organization facilitates a cleaner, more maintainable codebase. In this architecture, the Application Domain or API layer generally holds the reins - it knows the entirety or at least the crux of what the application is supposed to do. Consider an example, a command like dealing with some hardware api.SwitchOnLight(green); or dealing with a vector database api.UpsertDataSourceAsync(string context, string url);. Here, the API knows about the functions it's supposed to perform, that is, turn on the light to the green color or update an existing vector in the vector database. When the API is requested to perform these operations, it communicates with underlying modules to carry out the task. For anything related to database operations, there comes the Data Access Layer (DAL). This concept is consistent with the Repository Pattern as interpreted by developers. However, a question arises: what about when the API has to deal with external systems like a lighting or a hardware system? Here, we need an architecture that seamlessly integrates all kinds of external services - a more specialized layer such as a Hardware Access Layer (HAL) for hardware interaction along with DAL for database interaction. So, we rather talk about Service Layers than Repository Pattern, which is a special case in more simple applications. Peek into the realms of Windows, and you may encounter HAL - an age-old concept that continues to deliver. From the perspective of the API, to switch on the light, the code might look like this: SwitchOnLight(color) { _hal.SendMessage(new Message{ clr = color, intensity = default}); } The HAL implementations include HttpAccessLayer, ZigbeeAccessLayer, etc., each designed to communicate effectively with a particular set of hardware. The only thing they need to know is how to speak the hardware's language, not anything specific about the application. However, note that a design flaw often seen is letting the DAL or HAL know too much about our application. Continuing with our earlier example, the following design would not be ideal: UpsertDataSourceAsync(string context, string url) { _dal.UpsertDataSourceAsync(context, url); } In this case, the DAL knows about url and contexts. These are application artefacts. It's essential that layers are as ignorant about the application as possible, meaning completely ignorant. The main idea is to make these layers as reusable as possible. Independent on reusability, it is good to follow single responsibility pattern in each component. Consider transporting this layer to another application that needs to work with cars and houses data - having to handle context, url or any application specific detail might not be the best approach. A better approach for DAL design would look like this: UpsertDataSourceAsync(string context, string url) { _dal.UpsertVectorAsync(dataSourceCollectionName, new Payload{ url = url}); } Here, the DAL takes the responsibility of creating the payload in the given collection of the vector database. The API that implements UpsertDataSourceAsync is the only player here that needs to understand the bigger picture (context and url), allowing the DAL and HAL to remain efficient, simple, and reusable. To conclude, the modular layered architecture truly shines when it comes to separating concretes from the abstracts, enabling the creation of a versatile, reusable, and maintainable backend architecture.
Starting with the Qt 5.13 release, due end of May, the Qt OPC UA API in combination with the Unified Automation backend officially supports secure connections to servers (Sign or SignAndEncrypt message security mode). The following article outlines the ch
zum Artikel gehenIn an attempt to address the impact that the backlog in processing outcomes on waiver and visa applications has on foreign nationals, the Minister of Home Affairs has approved that some temporary measures will be introduced to address the situation. The t
zum Artikel gehenIn this blog we explain how to provide OPCUA open62541 as a ffi plugin to Dart and use it in Flutter. We highlight the pros' and give you the cons. Continue reading Flutter FFI Plugins How to use open62541 in Flutter applications at basysKom GmbH.
zum Artikel gehenQt OPC UA is not included in the Qt installer and must be built from source. The open62541 backend is currently the most stable and feature complete open source backend in Qt OPC UA. The open62541 library has minimal external dependencies and can be built
zum Artikel gehenLearn how to use Rive within Qt and Qt Quick. Rive is a tool (and file format) that enables you to create interactive vector animations. With the RiveQtQuickPlugin, you can effortlessly load and display Rive animations within your QtQuick projects. In thi
zum Artikel gehen