Working name: “Ausauschbares Protokoll”/”Auskoll”
A software architecture/design (herein architecture) that is programming-language agnostic to which provides a functional foundation for a server/cloud/webapp (herein webapp) application. This architecture design utilizes two distinct components being database and protocol, most notably, a SQL database and an HTTP. The database and protocol are agnostic to each other to enable replacement and expansion of either component.
The architecture is simple when drawn out. But do not look at the above image and concluding you know what’s going on. Each point requires an explanation. Firstly, the entire Architecture above is an abstract representation of 3 separate modules (1.1, 1.2, 1.3) in an application/network/service. This architecture is not exclusive/comprehensive, meaning more modules may be at play in your implementation.
Below are the elaborated definitions of the Auskoll architecture. Each elaboration will have a practical example of a client relationship management (CRM) application
1.1 – Core
We designate ‘Core’ as what the database and protocol have in common. The core is abstract, but simply put, it represents all code that is not proper to the database nor the protocol.
The core will contain a list of function declarations (but not their definitions) that will be defined by the Database and called by the Protocol. This fabricates the pseudo-interface 1.6 between Database and Protocol.
For example, in a CRM this would be all code regarding the exact structure of a client, what it means to be a client, and what can be done with a client.
1.2 – Database
The database module will be used for the persistent storage of information. Code in Database is used for storage, retrieval, deletion, sanitation, etc. It may be a MySQL driver, it may be a Postgres driver, it may even be just a memory-based database. The exact details of how this becomes interchangeable will be discussed in 1.6.
For example, in CRM this would be all code regarding the storage of new clients and their relationships using a MySQL driver.
1.3 – Protocol
The protocol is the way for the masses to communicate with the application/network/service. Most popularly this will be a Hypertext Transfer Protocol (HTTP) service, it may also be raw TCP, UDP, WebSocket, or it may simply be a file descriptor. The exact details of how this becomes interchangeable will be discussed in 1.6.
For example, in a CRM this will be all code that opens up an HTTP REST API to allow the webapp to access information to show the user and allow the user to submit more data.
1.4 – Protocol-Core interface & 1.5 – Database-Core interface
Explaining 1.4 and 1.5 is best done at the same time for reasons that will become clear.
As mentioned in 1.1, the Core will contain only a list of function declarations, not their definitions, we refer to this list of function declarations as Auskoll-functions. The Auskoll-functions will be defined by the Database at compile-time (1.5), and then called by the Protocol during run-time (1.3).
For example, in a CRM the code in the HTTP handler will be completely agnostic to the exact implementation of how the MySQL database works. The HTTP handler will only know about the functions to which it can call. Likewise, the MySQL code will be ignorant of what is exactly trying to use the database.
1.6 – Database-Protocol pseudo-interface
Because of the relationships defined as 1.4 and 1.5, there is a “pseudo-interface” that is made between Database and Protocol. Unlike a normal interface, this “pseudo-interface” forces both the Database and Protocol to be created without knowing the details of the other. This means that either Database and Protocol can be interchangeable/replaceable with implementation. This relationship is powerful as it makes all combinations of database and protocol.
In the CRM example: if we wanted to add an external Postgres database and have it interoperable with our current HTTP frontend. We’d simply need to write code that connects the Postgres database and define the Auskoll-functions within that code. And that’s it, our frontend nor our HTTP code requires any modification.
Relationship to MVC Architecture
The model-view-control (MVC) architecture can be laid under the Auskoll Architecture to draw an analogy. The database can be seen as the model, the protocol can be seen as the view, and lastly, the core being the Controller.
Note that these Archietcures are not interchangeable. They are similar and arguably Auskoll is a subset of MVC with more restrictions and more concrete practices. Most MVC implementations tend to target to be interchangeable. Auskoll does this but in a very concrete way.
Ellem has several internal libraries that use Auskoll architecture. Dossibay, Ellem’s subsidiary, uses these libraries. Ellem has plans to release these libraries as a separate product in the near future.