The monolithic architecture is the most commonly used software architecture pattern in enterprise software development. The term monolithic means formed of a single large block.

A monolithic architecture also describes a single tiered software application in which different components are combined to form a single platform where all software components must be present in order for code to be compiled or executed.

This architecture pattern can also be multi-tiered and multi-layered. A tier is a physical unit where the code runs, example a web server or a database, whereas a layer is a logical unit that organizes code, example a business logic layer.

The below diagram presents a monolithic architecture using .net core and Xamarin for mobile development. It is a multi-tiered and multi-layered architecture.

This architecture is based on the n-layered architecture pattern, 3-tier internet architecture and plugin architecture pattern. It includes REST, Service Orientated Architecture (SOA) and Inversion of Control (IOC) architectural styles.

This monolithic architecture provides code blocks for separation of concerns to enhance simplicity, maintainability and extensibility. Each layer contains testable components and the layered architecture caters for a multi-tiered setup. The architecture is portable to be deployed to a cloud environment and allows for the data layer to be mocked to enhance component software development.

Data Store Layer

This layer of the architecture is the actual data store for the software system. It is also known as the persistence layer. It consists of different types of databases (embracing polyglot persistence), example Microsoft SQL Server Database, Azure Cosmos Database, Redis, etc.

The data store layer only transfers data to and from the data layer using the context components contained within the data layer. No other layer apart from the data layer can communicate with this layer.

Communication between the data layer and the data source layer is performed using a business model (which is defined in the shared layer). The database model will be converted to a business model in order to transfer data to and from the data store.

Services Layer

The services layer of the architecture is very similar to the data store layer. The purpose of this is to separate communication with external systems (third party services) and to keep it in a section of its own (separation of concerns). External systems can be other SaaS systems, file server, etc.

This layer only transfers data to and from the data layer using the service components contained within the data layer. No other layer apart from the data layer can communicate with this layer.

Communication between the data layer and the external services layer is performed using a business model (which is defined in the shared layer). The external service model will be converted to a business model in order to transfer data to and from external sources.

Data Layer

The data layer is the layer responsible for transferring data between the business layer and the data store or external source layers. This layer has no logic and essentially handles create, read, update or delete (CRUD) operations within a transaction. The following building blocks are contained within this layer:

Data Access Components

A data access component is created to communicate with at least one database in the data store. A data access component cannot communicate with another data access component. Communication with a database is achieved by injecting the appropriate data context component. Data access components can inject more than one data context component.

Data Context Components

A data context component handles converting a business model to a database model and vice versa. It also communicates directly with a database in the data store. A data context component cannot communicate with another data context component and can only interact with one database. Note that it is suggested that an Object Relational Mapper (ORM) be used to interact with a relational database. For non-relational database, an ORM is not necessary.

Having data context components allows for mocking source data during component development in the implementation phase of the software development life cycle.

Data Service Components

A data service component handles communication with an external service. It is recommended that a data service component handles communication to a single external source. A data service component cannot communicate with another data service component.

Having data service components allows for mocking services during component development in the implementation phase of the software development life cycle.

Business Layer

The business layer handles all business logic, validations and business processes. This layer is also responsible for transferring data from the application façade to the data layer or from the data layer to the application façade layer. The following building blocks are contained within this layer:

Business Components

A business component is created to run a set of business rules, validations and/or communicate with one or more data access components and/or one or more data service components. A business component cannot reference other business components.

Business Process Components

A business process component is created to handle processing of big data or to run a defined business process using a number of business components.

Application Façade Layer

The application façade layer consists of the Authorization Server and Resource Server. It exposes modules via a REST API (through the Resource Server) with easy to read methods for the caller and communicates with the business layer to handle requests and responses.

This layer also handles the security for the application.

Presentation Layer

The presentation layer contains all user interfaces (UI) exposed to a user. It references the application layer by consuming its exposed REST API via a Uniform Resource Locator (URL).

This layer provides two types of user interfaces, namely web and native mobile applications. The web application will require scripted components whilst mobile applications will require shared UI components when using the Xamarin framework.

External systems utilizing the API are illustrated in this layer. This is needed when the system is exposed as a SaaS deployment model.

Shared Layer

The shared layer consists of files and projects which can be used in any layer. A shared layer project does not contain references to any of the other layers. This layer contains the following:

Assembly Information

This is a shared file used by any project created within the software solution to handle version information. If the software version is to be incremented, only this file is required to be updated.

Code Analysis

This folder contains the rules for code analysis. Suppression files used to resolve project specific code analysis errors are also included. Code analysis should be set up to use all Microsoft rules for best coding practices. It is suggested that code analysis is always enabled when building the solution on the chosen development platform. Test projects do not need code analysis to be enabled.

Strong Name Key

This is the shared Strong Name Key (SNK) file used to sign assemblies. SNK is required if assemblies need to be added to the Global Assembly Cache (GAC) and to protect the development team if assemblies are going to be used in other projects. Note that the architecture does not require assemblies to be placed in the GAC, however it is best practice to have assemblies signed. If assemblies are to be signed, then referenced third party libraries also need to be signed.

Model

This is essentially a number of classes forming a business model (or domain model) used to communicate between layers. Enumerations are also contained within this project. It is a light weight project with only the properties and methods needed to define a business model. Domain Driven Design (DDD) may be followed to improve a business model definition.

The Model project should be built using the .NET standard library so that it can be shared with the Xamarin mobile project.

Framework Layer

The framework layer covers any cross cutting concerns between layers. It essentially houses the reusable blocks that can be used in different layers. Contents of this layer include the following:

Configuration

Any configuration not contained in the data store will be covered in this block. If dependency injection is used in the framework, its configuration may be located in this block.

Exception Handling

Exception management for the software system is managed in this block. Critical exceptions are to be logged however user friendly messages are to be displayed to indicate a failure. Exceptions should be allowed to bubble all the way to the boundary layers. Only exceptions that can be caught should be handled. The design should not leave the application in an unstable state when an exception occurs. This block also includes custom exceptions.

Security

Advanced security logic pertaining to encryption and decryption for sensitive data is covered in this block.

Logging

This block covers the logging tools that can be used by other layers.

Summary

There are a number of architectural patterns available, each with its own pros and cons. Choosing an architectural pattern depends on the scenario or project requirements.

Monolithic architectures are simple to build, test and deploy. Applications built with this architecture can scale horizontally by running several copies of the application behind a load balancer.