Home · Language Reference · Index · Source code

The Application Layer

In a , the which is important to users lives in a remote store, not on their device. Clients will want to perform many different types of actions on diverse data, and will want a simple interface via which to perform those actions. The data store is usually an off-the-shelf database system like MySQL or MongoDB; writing a bespoke storage engine is needless work for most systems.

Most databases provide query logic to aggregate, filter and join data, but do not provide an ergonomic environment for general-purpose programming. They may also provide access control to the level of individual rows but not columns.

Writing domain logic in off-the-shelf database systems is difficult, and providing clients direct access to a database is insecure.

In order to provide a simple interface for clients to present their use-cases to the server, some intermediate step in front of the database is necessary. Sometimes two different actions for different use-cases will access completely different sets of data in the store. This leads naturally to the application layer being “broad”, and sometimes “shallow” if the actions are simple changes to the data in the store.

@startuml !theme plain == Request for use case 1 == Client -> Application : Use case 1 Application -> Database : Access dataset 1 Database --> Application Application --> Client == Request for use case 2 == Client -> Application : Use case 2 Application -> Database : Access dataset 2 Database --> Application Application --> Client @enduml

In real applications there is often data that must be accessed all the time (e.g. the client’s current session), and there may be a variety of data stores used, not just a single one. This tends to make the application layer a “mediator” which takes a single request and translates it into many sub-requests to various other systems, waits for their responses, and synthesises a single response to reply to the client with.

Therefore, create a layer of software that runs on the server and mediates access between clients and the data store. Call this layer the “application”. Its role is to provide interfaces to clients which satisfy their use-cases, and to ensure that each interface manipulates the data in the store in a consistent way.

Typical application architectures for web systems mean that the application layer will be . Make the application layer (and therefore use a stateless protocol design like REST).

Business/domain logic should live in the application layer. The application layer is also concerned with authorization, and possibly authentication.

The application layer interface may be designed for machine use by a rich, , or it may be present content designed to be consumed by a thin client like a browser.