Applying hexagonal architecture to a 10 year old monolith

php-barcelona-2019-cfp.md

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.

it is obsolete within the PHP ecosystem, as it does not take advantage of the last features of the language and its packages

Why would this make it obsolete?

Using this architecture will allow us to make each component more independent and robust: it will be easier to add, extend or modify any component, besides having testing for each new element.

At this point I thought it sounded like blind hype...

but we will also explain the missteps and drawbacks we found during this big refactor

...but this made it sound good again. Discussing the drawbacks and issues you found is really good - we shouldn't just talk about the advantages of new approaches. Maybe put this up front a bit more? "Using this architecture will hopefully allow us to"?

Thank you for your comments, they are really appreciated!

it is obsolete within the PHP ecosystem, as it does not take advantage of the last features of the language and its packages

Why would this make it obsolete?

You are right, it does not make it obsolete per se, it is simply not updated. After re-reading it, that paragraph did not convince me, so I removed it.

...but this made it sound good again. Discussing the drawbacks and issues you found is really good - we shouldn't just talk about the advantages of new approaches. Maybe put this up front a bit more? "Using this architecture will hopefully allow us to"?

Fixed! I also changed "will" by "should", as it is not something certain until it is fully finished.

Thank you again!

In my opinion the abstract is a bit too long.
For the intro you might want to consider making it a bit shorter like

Our CMS, Brancam, is over 10 years old and a dozen of developers have worked on it. During this time a lot of developers have worked on it without any proper guidance....etc.

Now that you have the problem 'explained', go to the hexagonal architecture and how it fits with the current MVC site

Also, is it a 'we' talk or an 'I' talk?

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:

1. What is a hexogonal architecture and what are the benefits/why is it important.
2. Brancam is a project that can illustrate the benefits and difficulties of moving to this architecture
3. Basically your final paragraph with some minor edits to fit the shorter format

Thank you for your comments, @Jandev and @remotesynth !

In my opinion the abstract is a bit too long.
For the intro you might want to consider making it a bit shorter like

You are right, I will make it shorter.

Also, is it a 'we' talk or an 'I' talk?

It is an "I" talk, but I always have the same doubt: is it better to write "I" or "we"? Or maybe I can change the expressions to be "we will see", as it will be seen together with the audience.

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"

It was never my intention to be a pitch for a product, but now that you point it, I see that in can seem like that. I will change it ;)

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:

1. What is a hexogonal architecture and what are the benefits/why is it important.

2. Brancam is a project that can illustrate the benefits and difficulties of moving to this architecture

3. Basically your final paragraph with some minor edits to fit the shorter format

That is actually a good structure. I was under the impression that the topic of the talk will be near at the end, but I did not know if that was something to modify or not. With your comment I see it, so I will change it.

I will work on a new version today and tomorrow, to apply the changes you both mention. Thank you again, guys!

I just submitted again to helpmeabstract.com in case that someone is willing to take a look at the new, improved version. If not, that would be okay, I already had great help :)

This looks much better to me. Best of luck with your submission!

@remotesynth Thank you! I think it looks much better now, thank you for your comments! ;)