A Rundown of the Hexagonal Architecture @Sixt

Sixt India
Sixt Research & Development India
4 min readFeb 18, 2020

By Swati Sinha

Photo by Ilnur Kalimullin on Unsplash

Most applications at Sixt usually revolves around microservices architecture which is based on the “Hexagonal Architecture” and Sixt’s own architectural principles.

The Hexagonal architecture is also known as the “Ports and Adapters architecture”.

The architecture gets its name for its most obvious feature — input and output are placed on the edges of the hexagon. Therefore, the central logic gets isolated from any outside concerns.

Architectural Principles at Sixt:

· Each service is written with minimized coupling. Coupling is the measure of interdependence amongst the services. And, the ‘micro’ in Microservices is about minimizing coupling and not limiting the lines of code.

· Each service is required to expose a well-defined API. Any data access from external sources happens via this API. No direct access to the database is allowed.

· Each service should be ‘killable’ at any point and not lead to any data inconsistency.

· Each service should be horizontally scalable, unless otherwise required by the business logic of the service. By the term ‘horizontally scalable’ we mean systems whose capacity and throughput are increased by adding additional nodes.

· Each service should be tested independently. The business logic should be tested separately and the infrastructure specific parts ( DB read and writes , kafka writes, etc.) should be tested separately.

Now, let’s discuss each of the stereotypes within this architecture. While discussing these, we will consider a banking application.

Photo by Rob Hampson on Unsplash

A Pictorial Representation of the Hexagonal Architecture :

Domain Object or Model:

· In our example of the banking application, a customer debits an account and a statement is issued to the client. These are typical interactions that occur between the objects of the domain.

· In a domain rich environment with business rules, domain objects are the lifeblood of an application. Domain objects can contain both, state and behaviour. The closer the behaviour is to the state, the easier the code to understand, reason about, and maintain. These domain objects don’t have any outward dependency. The Outward dependency refers to the concept where the business logic is not dependable on any of the database or any external component.

· As, domain objects have no dependencies on other layers of the application, changes in other layers don’t affect them. They can evolve free of dependencies. For our domain object, the only reason to get changed should be the change in the business requirements.

Application Service:

· In the above banking application example, the application service will define a use case — deductAmtFromAccount.

· This is the use case of our Application, abstract descriptions of what users are doing with our software.

· Similar to the domain objects, a use case class has no dependency on outward components.

Input and output Ports:

· An input port is a simple interface that can be called by outward components and is implemented by a use case. An output port is again a simple interface that can be called by our use cases if they need something from the outside (database access, which contains the customer and account details).

· We saw that the Domain Objects and Application service are within the hexagon. These components need to communicate with the outside systems as well. These communications happen through these dedicated Ports .

With the help of these ports, we have distinct places where the data enters and leaves our system.

Adapters:

· Input adapters or “driving” adapters call the input ports to get something done. A common example of the an input adapter could be a web interface.

Output adapters or “driven” adapters are called by our use cases and might, for instance, provide data from a database.

· The outer layer of the hexagonal architecture is formed by the Adapters. They are not the part of the core but they help in interacting with the core.

The adapters make it easy to exchange a certain layer of the application.

That was a quick overview of the Hexagonal Architecture @Sixt. Let me know your insights in the comment section below.

--

--