Hexagonal Architecture - The Why

Why Hexagonal Architecture? Do we really need it or is it just an overhead?

Why Hexagonal Architecture?

Isn't the traditional 3-layer architecture enough?

Is Hexagonal Architecture just an unnecessary overhead?

The above are common questions asked by developers. Instead of saying that one is better than another, we must ask ourselves, what problems does it solve?

The team started with a single-layer MVC app.

There was a team who needed to implement an eCommerce app. Initially, they just implemented a simple single-layer MVC app; where UI, BL, and DB are all intertwined. They did manual testing, and it was all fine. After all, the business logic was straightforward, it was just a simple CRUD app, and the manual testing didn’t take too long either.

But then business logic & test scenarios grew!

As the business requirements evolved, business logic increased. This also led to a growth in test scenarios. It was no longer feasible to manually test the application. So the team added automated UI tests.

However, even that wasn’t sustainable because the UI test suite became slower and slower as the test scenarios increased. Furthermore, the developers found it hard to maintain the app when the UI and BL code were intertwined.

So they moved to a three-layer MVC app.

So then, the team decided to move from a single-layer MVC app to a three-layer MVC app, with separation between UI, BL, and DB access. In this way, UI and BL were separated, and the BL could be tested independently of the UI.

But the UI & BL were still intertwined!

Since the UI layer was referencing the whole Business Logic layer, it meant the UI layer could directly make calls to any objects in the BL layer. Furthermore, developers accidentally started adding some logic to the UI layer itself. And as we had additional presentation mechanisms (e.g., MVC controllers and REST API controllers due to third-party systems), the team saw inconsistencies in the logic at the representation level.

So they introduced an “interface“ to the BL.

By introducing an interface as the entry point to the business logic layer, it meant that there was a clear separation between the presentation and business logic.

But then, the DB layer needed to be changed.

The team needed to make changes to the DB layer. Sometimes, it was due to an upgrade in the ORM, switching from an ORM to SQL, switching to a micro-ORM, or even switching to a different database. Additionally, due to many BL test scenarios, the test suite became slow as each one was calling the DB.

Furthermore, they asked themselves, does it even make sense for BL to depend on the DB? Does it make sense for them to be coupled if they change due to different concerns?

So they introduced an “interface” to the DB.

They introduced an interface for the persistence layer. That interface represented operations such as adding an object to the persistence mechanism, retrieving it from it, etc. Now, they could swap out the database.

It meant a clear separation between BL and DB; BL was no longer dependent on the DB. Furthermore, the BL tests could be executed without the DB - resulting in fast-running BL tests.

Watch this step-by-step on YouTube

---