Using the Hexagonal architecture style allows for delaying architectural mechanism decisions and promotes using the same internal API irrespective of type of client, Vaughn Vernon explained last week when talking about architecture styles from a Domain-Driven Design, DDD, perspective; the classical Layered Architecture and the more advanced Hexagonal and Actor Model styles.
Vaughn Vernon, author of Implementing Domain Driven Design, after a short talk about how architecture emerges as a result of proper domain modeling, started by analysing the classical standard layer architecture from Eric Evans' DDD book, with a user interface layer at the top and an infrastructure layer at the bottom. An undesirable effect of this layering is that the implementation of e.g. domain repositories in the infrastructure layer breaks the architecture since repositories depends on the domain model. Moving the infrastructure to the top and using the Dependency Inversion Principle to inject dependencies prevents breaking the architecture and also makes it more flexible by allowing for different implementations to be injected.
Hexagonal architecture style
Vaughn continued with the Hexagonal, or Ports and Adapters, architecture style created by Alistair Cockburn. Vaughn sees this style as an evolvement of the layered style with two main advantages. It allows for delaying decisions for certain architectural mechanisms, e.g. what kind of persistence to use without impeding the progress of building functionality. Main point though is that thinking in terms of ports and adapters make it easier to use the same internal API for different kinds of clients.
An Event-Driven Architecture can be derived from this style with each bounded context as a hexagon, publishing and subscribing to events.
Actor Model
In the actor model, each object is an actor with a mailbox and behaviour, with messages exchanged between actors through the mailboxes. All communication is performed asynchronously and without shared state between the actors. Vaughn finds this model most interesting and is now experimenting with applying the actor model in a DDD style by implementing aggregates as actors, inherently getting self-contained state, no shared state and asynchronous messaging, to greatly simplify the use of concurrency in highly scalable systems.