agsandrew - Fotolia
A quick rundown of 3 layered architecture design styles
N-layer, hexagonal and onion are all layered architecture styles, but each one features its own unique spin on distributed design and modular development.
It's possible that the greatest insult you could hurl at an application architecture is to call it monolithic. After all, confining the totality of application logic to a single software element makes distribution, scaling and redeployment markedly difficult, if not impossible.
Architects looking for alternatives to the monolith take many models into consideration, but there are three layered architectural styles that particularly reflect the mental evolution of ambitious software managers: the N-layer, onion and hexagonal models. Let's examine each one and gain a better understanding of their specific structure and architectural implications.
N-layer architecture
N-layer is a commonly-used layered architectural style, although some would argue it's not an architecture as much as a deployment model. Its basic schema divides an application into three successive layers:
- The user interface;
- the supporting business logic; and
- the database access
The challenge that N-layer creates is that it doesn't explicitly define each layer's responsibility, the directional flow of information or identify dependencies. Typically, it also presents tight component coupling, so changes in one layer will often require changes in the others. This reduces the benefits of modular programming, which cherishes independent service deployment and management.
The dependency issue has led architects to create the other models that are worth considering: hexagonal and onion.
Hexagonal architecture
The hexagonal architectural style splits applications into three layers, similar to the N-layer model. However, components are loosely coupled via collections of ports and adapters. The model outlines that the core application has specific features or services that can be accessed through the ports, which are connected through (or even generated by) the adapters. This model makes the software's functions and capabilities the centerpiece of the architecture.
The criticism often levied against the hexagonal layered architectural style is that it doesn't elucidate the inherent difference between the services that provide data and the services that consume it. More recently, some developers also complain that it doesn't fully encapsulate the importance of the user interface, which is the primary driver of the cloud portion of hybrid applications today.
Onion architecture
The final model combines the implementation-oriented nature of N-layer with the service-oriented nature of hexagonal architecture. The onion model bases itself in object-oriented programming. The center of the allegorical onion contains the foundational domain entities and objects, which are the elements of the software that have no dependencies.
The repository and service layers of the onion represent database and common operations services. It's a principle of these two layers to separate the interface from the implementation, to ensure loose coupling and reduce dependency issues.
Finally, the outermost layer contains the user interface, which collects the service and application information through the abstracted repository and service layer, maintaining separation between the interface and the underlying, domain-level entities and objects.
Which model fits your architecture the best?
The N-layer model lends itself to traditional client-to-server implementations, but is not well-suited for more modern cloud deployments or microservices development. Instead, consider N-layer as a steppingstone from monolithic applications to hybrid cloud deployments.
The hexagonal model and the onion model are similar, but architects working with microservices and building applications through composition tend to favor the clean model, thanks to its service-centric nature. The most important thing to remember is that you'll need to consider your model choice carefully -- it's difficult to change horses mid-stream.
