Eric Honorez erichonorez

A Gentle Introduction to Hexagonal Architecture

Background

Frameworks are great. They helps us to gain productivity improve quality and unify practices. Because of our needs evolve the framework we choose today could not be the one we will need tomorrow.

Moving from a framework to another may involve a complete refactoring of the application if its architecture is not flexible enough. This is expensive, risky and often hard to justify to the business.

Application's business behaviors should not be impacted by moving from one framework to another.

Hexagonal Architecture

Microservice architecture is not a software development approach

Microservices are often presented in contrast of monolithic applications which are frequently associated to a Big Ball of Mud. If your application is a BBoM don't expect microservices will help. They are not a turnkey solution to good design and modularity.

I think that it is really important to understand that microservices are just an architecture style. It's nothing more than Service Oriented Architecture with a couple of opiniated patterns, principles and practices. These tools give guidelines in order to create distributed systems. The main goal of this kind of architecture is to enable different teams to work autonomously on different part of a system and thus improve the overall productivity. When well applied microservices are an investment that will allow you to quickly evolve and make choices independently from other teams.

Microservices won't help you to improve the quality of your code. This architecture style is not a solution

	package example

	trait Animal {
	def name: String
	}
	case class Cat(name: String) extends Animal
	case class Dog(name: String) extends Animal

	trait SmallAnimal extends Animal
	case class Mouse(name: String) extends SmallAnimal

	{-# LANGUAGE OverloadedStrings #-}

	module IssueTracker where

	newtype RepositoryId = RepositoryId String deriving (Eq, Show)
	newtype OccuredOn = OccuredOn String deriving (Eq, Show)
	newtype UserId = UserId String deriving (Eq, Show)
	newtype Label = Label String deriving (Eq, Show)
	newtype DateTime = DateTime String deriving (Eq, Show)
	newtype MilestoneId = MilestoneId String deriving (Eq, Show)

	package com.example.demo;

	import java.util.Arrays;
	import java.util.List;
	import java.util.UUID;

	import lombok.Value;

	import static io.vavr.API.$;
	import static io.vavr.API.Case;

	package com.example.demo;

	import java.util.Arrays;
	import java.util.List;
	import java.util.UUID;
	import java.util.stream.Stream;

	import lombok.AllArgsConstructor;
	import lombok.Value;

	package com.example.demo;

	import lombok.Value;

	/**
	* This example implements event sourcing using with versioning. It uses
	*
	* Each version has its own event interface (e.g. {@link EventV1} and {@link EventV2}) that extends the {@link Event}.
	*
	* In order to apply {@link Event} on a {@link State} the visitor pattern is used. Each version also define its own visitor interface (e.g. {@link VisitorV1} and {@link VisitorV2}). All visitors are aggregated with the {@link Visitor} interface.

	// Start writing your ScalaFiddle code here
	import scalaz._
	import Scalaz._


	case class LoanApplication(
	val firstName: String,
	val lastName: String,
	val nationalRegister: String,
	val emailAddress: Option[String]

	import scalaz._
	import Scalaz._


	sealed trait Transaction {
	def value: BigDecimal
	def apply(amount: BigDecimal): BigDecimal
	}
	case class Credit(value: BigDecimal) extends Transaction {
	def apply(amount: BigDecimal): BigDecimal = {

	// Start writing your ScalaFiddle code here
	import scala.util.{Success, Failure}
	import scala.concurrent._
	import scala.concurrent.ExecutionContext.Implicits.global
	import scalaz._
	import Scalaz._
	import scalaz.OptionT._

	type User = String
	type UserDetail = String