The Micro-Hexagon Design Pattern to Architecture Pattern, Part 1

Although microservices solve many technical problems, it is time perhaps to conclude, after a few years from the launch date of this concept, that this architecture needs to be further improved, to provide a way to have a clearer vision of the functional components. That's why many architects now use DDD decomposition.

Another concept that has been put in place with DDD is event sourcing and CQRS. In fact, we do not deny the benefits of these implementations but it could also have other technical drawbacks which impact our architecture with more complex debts.

In this situation, I have restored the basic concepts of the hexagonal architecture which have been neglected since 2005 by many developers and I will show you how it will help us to solve the above issues.

Alistair Cockburn defined hexagonal architecture as the architecture of port adapters. The name can give you an idea about the concept. But this architecture also has disadvantages, such as inflated functions.

Every design has its own advantages, but what about combining MSA, CQRS, and HEXA? I have noticed that many developers try to implement CQRS and event-driven architectures in every software component, but they would have bad moments in production environments. We will discuss this in future posts.

I have searched for a while for a compromise between complexity and power, and here I am suggesting this architectural design based on Alistair's Architecture.

In this area, we will exchange only functional needs, and we will use business language (please do not be confused by DDD UL).

This will allow us to be more aligned with the principle of digitization and to transform our vision into a true digital strategy based on customer insights and the market. First of all, we should think 100 percent business, then we should adopt our functional components to the technology trends (be aware of over-engineering).

Let's focus more on our atomic component: the micro-hexagon.

In fact, according to hexagonal architecture, we will divide our microservice into three levels:

1. Application Side
2. Domain Side
3. Infrastructure Side

The top layer of this architecture will be a microservice layer. We will isolate boundaries using ports and adapters.

Dependencies range from the application to the domain and from the infrastructure to the domain. It is a good way to manage integration projects and tests. The package will be organized by business cases. Think 100 percent business. If we also talk digital, we need to go after technological trends and sometimes, we will exert a lot of effort and cost to be aligned with the new technologies. This micro-hexagon is a flexible way to manage adapters, to mitigate the risk of evolution, and to have a safe business domain.

Sometimes business models are more important than technology projection, but by using this architecture style it's easy to find and identify the business rules. It would also be a great advantage to the new development team members who start in an early stage of the development phase to understand the business cases treated from one part and to master the technological part of the infrastructure.

Development frameworks and purely technical services are being used more and more and they have reached a good level of maturity. We use several types of IOC containers every day and we carry out third-party dependencies which facilitate implementations.

But suppose your Postgres database is changed by Hadoop or Mongo or the inverse (just an example) according to the strategic view of the enterprise. Now imagine the technical debt you will have.

How will this sudden change impact your development and your solutions that are already in production?

By using a micro-hexagon architecture, we could be aligned with the agnostic technology concept present in microservices, and we can give flexibility to our code base as well. You should also consider changes applied to the outer layers, intra-service interactions, and inter-service interactions that enable you to refactor the outer layer without impacting the inner layer.

QA managers will also be happy to handle test cases driven by hexagonal-based architectures. With this in place, it becomes easier to test our most valuable assets without mocks. That means writing faster and more concise cases for a specific area.

So to this post, I would say that if you are looking for an architecture that's flexible, maintainable, easy to test and implement, and allows you to focus more on business logic, go straight to micro-hexagon. Stay tuned for Part 2!