Introduction

Preface

It is hard to fulfill these requirements because software projects (or projects in general, for that matter) usually do not go as planned. Managers are drawing deadlines all around the project team$^1$, external partners build their APIApplication Programming Interfaces differently from what they had promised, and software products we depend on often do not work as expected.

And then there is our own software architecture. It was so nice in the beginning. Everything was working well. But then the deadlines pressed us into taking shortcuts. Now, these shortcuts are all that’s left of the architecture, and it is taking longer and longer to deliver new features.

Our shortcut-driven architecture makes it hard to react to an APIApplication Programming Interface that had to be changed because an external partner messed up. It seems easier to just send our project manager into battle with that partner to tell them to deliver the APIApplication Programming Interface we had agreed upon.

Now we have given up all control over the situation. In all likelihood, one of the following things will happen now:

• The project manager is not strong enough to win the battle against the external partner.
• The external partner finds a loophole in the APIApplication Programming Interface specifications, proving them right.
• The external partner needs another < enter number here > months to fix the APIApplication Programming Interface.

Regardless of which happens, we need to fix it ourselves because of the nearing deadline.

We add another shortcut.

Instead of letting external factors govern the state of our software architecture, this course will teach you to take control yourself. You can do so by creating an architecture that makes the software soft, as in “flexible,” “extensible,” and “adaptable.” Such an architecture will make it easy to react to external factors and take a lot of pressure off our backs.

What is the goal of this course?

I wrote this course because I was disappointed with the practicality of the resources available on domain-centric architecture styles like Robert C. Martin’s “Clean Architecture” and Alistair Cockburn’s “Hexagonal Architecture.” Many books or online resources explain valuable concepts but do not teach actual implementation.

That is probably because there is more than one way of implementing such an architecture.

This course will fill this void by providing a hands-on code discussion about creating a web application in the Hexagonal Architecture style. To live up to that goal, the code examples and concepts discussed in this course provide one interpretation of how to implement a Hexagonal Architecture. There are certainly other interpretations out there, and I do not claim mine to be the silver bullet for all situations.

I certainly hope, however, that you will find some of the concepts in this course helpful enough to include them in your own toolbox.

Who should take this course?

This course is aimed for software developers of all experience levels involved in creating web applications.

As a junior developer, you will learn about designing software modules and completing applications in a clean and maintainable manner. You will also learn some arguments for when to apply a certain technique. However, you should have some experience building a web application in the past to get the most out of this course.

If you are an experienced developer, you will enjoy comparing the concepts from the course with your own way of doing things and incorporating bits and pieces into your own software development style.