What do have clean, layered, hexagonal hexagonal, onion architecture and ports & adapters in common? They kind of share the same principles: Separation of concerns (business vs infrastructure code), data encapsulation (information hiding), low coupling, strict dependency flow (how layers should depend on other ones).

Still these concepts are not easy to digest unless you put them into practice. Furthermore architectural decisions are figured out based on personal, past experiences and the degree of knowledge people have when discussing viable solutions.

As already mentioned in Accelerate architectural decissions and effective architecture enable teams to easily test and deploy individual components/services also when the organization grows or the amount of services changes. Architectural characteristics rather than implementation details were more important in order to have a portable and sustainable architecture. As you define (logical) layers, clear boundaries and relationships between individual packages/modules inside your software, this will improve overall maintainability and testability of your code.

Some months ago I gave a presentation on “Hexagonal Architecture in Python” for the TECH team at Cashlink. More than a year ago, me and my ex-colleagues at Scout24 were implementing small services using the same principles, but in Golang. At that time I’ve found it rather easy to find examples for Golang. For Python I still miss examples of big projects embracing hexagonal architecture. (But maybe because I didn’t search as long as I did with Go … )

In this presentation I somehow mix “hexagonal architecture” and “ports & adapters” for architecting an application meant to upload documents to several storage systems (S3, Dropbox etc.) Let me know if you think this is useful and/or abstractions (as interfaces) are somehow obsolete in Python making code even unreadable.