Hexagonal architecture is a pattern of design that aims for a separation of concerns. It produces a decoupled system, where business rules are independent of the framework, UI or the database used.
There are two big benefits of using it. First, it is possible to test our business rules without the need of any UI, database or webserver. Second, it is possible to change any concrete implementation without affecting the core of our application, making framework updates easy.
In this talk, we will see the ongoing application of hexagonal architecture to Entrápolis, our ticketing product. Thought its code is not old, a dozen of developers have worked on it, mostly without any proper guidance, resulting in a code hard to maintain, hard to optimize and hard to add new features.
We will not only see the benefits of applying hexagonal architecture to our monolith, but also the missteps and drawbacks we encountered.
I'm going to suggest some major changes. First, by putting the product name in the title, it sounds like it may be a pitch for the product when in fact it is a "pitch" for a particular development pattern, with the key example of success being the CMS. I'd suggest a title more along the lines of "The Benefits of a Hexagonal Architecture" or something more dramatic like "Escaping the Monolith with a Hexagonal Architecture"
Second, have to agree with @Jandev that the abstract is long, but, more importantly, it doesn't actually get to the point until the very end. The history of Brancam is actually secondary since it is really just your example. I'd format it along the lines of: