Introduction

In a traditional MVC architecture, one would expect there to be a controller for returning the information from a Model and the Model will know its schema, manage its database logic and know some business logic.

It is immediately evident that the Model can be broken down into at least 5 pieces (Entity, Factory, Repository, Provider, Service) which makes for a more flexible application where more code can be reused because it is present within smaller services and assembled generically with depdency injection. As a result, Tramway has an n-tier architecture where the different layers are decoupled, which means microservice architecture is easier to support as it's easier to move layers to separate applications via the persistence and presentation layers.

Here's a high-level view of a microservice architecture where the primary data source of a given service is managed by another service.

The following layers can therefore be defined:

Persistence

The persistence layer manages communications with the data sources that will be used. The architecture is generic enough to permit this layer to be on the same, or separate application thanks to a standardized Provider class that decouples communications from the Repository.

Data

The data layer manages the data model but does not necessarily know how it will be persisted. This allows the application to be flexible if ever a data source needs to change, or a caching layer needs to be added. The details behind this data source are within the persistence layer and follow an interface to ensure cross-compatibility so the Repository doesn't need extensive changes. Furthermore, the translation from the data source would be facilitated with a Factory.

Logic

The logic layer contains Service classes which manage the business logic and transformations to the data that are pertinent to the application. Furthermore, there are times when some actions need to be loosely coupled, in which case the Service can contain a Dispatcher to pass Event objects to a Subscriber. The Subscriber can then employ another Service to assist in the task. The benefit is the Event is broadcast and there's no consequence if a Subscriber isn't present. In other applications, the same service that uses a dispatcher opens new possibilities to easily interact with a Pub-Sub architecture.

Orchestration

The orchestration layer manages communications between a client and the rest of the application. A Controller will facilitate the HTTP connections whereas a Command will facilitate a CLI interaction. The orchestrator will translate external information from the system such that internal layers can respond to the request. Once completed, the response is then passed to a presentation layer.

Presentation

The presentation layer manages how information is displayed to a client. On a traditional web application, a presentation layer would feature an HTML template where information is injected in. In the context of APIs, certain standards exist to ensure APIs are uniform - one example is HATEOAS. This layer also manages requests for certain formatting from a client. For instance, the same Collection or Entity that was returned by the Controller can be displayed as JSON or XML or even HTML depending on the Accepts Header.