Think Hexagonal Architecture for Cross-Platform Mobile Applications

N-tier or layered architectures have become so common for software applications over recent years that practical examples of an alternative in serious use can be hard to come by. I find that people are so used to thinking in terms of tiers and layers that they don’t necessarily consider that there may be an alternative way to think about their own applications.

I would argue that many cross-platform mobile applications are being built in a way that more closely resemble a Hexagonal Architecture.

Introducing Hexagonal Architecture

Hexagonal Architecture is also known as Ports and Adapters and was introduced by Alistair Cockburn. The basic premise being that the core application offers up a number of ports and can be configured to run with any combination of available adapters that can satisfy those ports. The internal application communicates through its ports to the supplied adapters without any knowledge of which adapters are in use.

Hexagonal Architecture

For example, a data persistence port might be configured to use an adapter representing one of several genuine database implementations or perhaps even an in-memory database adapter.

Many minor variations (such as Onion Architecture) exist but the basic intentions of the pattern are the same.

Hexagonal Architecture in practice

So let’s take the concrete example of a cross-platform Xamarin mobile application.

A common approach is to use the MVVM pattern to separate our presentation logic from the user interface itself. MVVM Light and MVVMCross are two popular frameworks for use with Xamarin.

When representing these kind of applications through Hexagonal Architecture, I like to think of the core application as consisting of two parts that are available to all configurations, the view models and the domain model. This is in contrast to the popular view of this pattern, where the core hexagon represents only the domain model.

View models in the hexagon

Ports in the domain model

When the shared codebase needs to access platform specific behaviour, the typical approach is to call out through a domain model interface to a run-time injected implementation. These make up the majority of ports and adapters in the system.

For example, this C# interface represents a port giving access to the file system:

    public interface IFileAccess
        Task<T> LoadAsync<T>(string filename);
        Task SaveAsync<T>(string filename, T data);

One or more implementations of this port sit outside the core application as potential adapters. This could include Android, iOS, Windows or in-memory file access implementations.

User interfaces as adapters

With MVVM in place, we can also think of the view models as a port to the user interface. The communication mechanisms in play when using a real user interface are those typically used with MVVM namely data binding, commands and INotifyPropertyChanged.

Alternatively, you might decide to create a console app or test version of your application. In which case you could interact with the view models directly, executing commands and querying data.

Bringing it all together

Typically, Dependency Injection is used throughout the core application, which then allows you to register your chosen combination of adapters through an IoC container to bring together your entire application.

Some of these will be specific to each configuration of the application, some of them will be shared. For example, SQLite is a popular database solution for use with Xamarin on Android, iOS and Windows.

Android application as hexagonal architecture

What have we achieved?

You might wonder what difference any of this makes. After all, the solution I have outlined here is no different to what many Xamarin projects are already doing. I’ve just described it using a different architecture.

Firstly, if we are going to consider the architecture of a system, then why wouldn’t you want to use the most accurate model available? And for me, hexagonal is a better fit than layers.

Also, our conceptual view of the software we are building has implications for how we discuss the system and how we organise and name elements within it. Even if you don’t actually create architecture diagrams, you would still want your system to be as self-documenting as possible. And the more your codebase communicates a convincing and accurate vision of the overall architecture, the more likely everyone working on it will be on the same page.


Read More:


2 thoughts on “Think Hexagonal Architecture for Cross-Platform Mobile Applications

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s