Skip to content
0:00 / 0:00

#hexagonalarchitecture#onionarchitecture#cleanarchitecture

Domain centric? Why Hexagonal, Onion and Clean architecture are answers to the wrong question by Oli

Devoxx

172K subscribers • 49 videos on Hallway • Conference channel

YouTube
  • One of the most-watched uploads on Devoxx, a conference or university channel Hallway lists. Nobody has recommended it in the communities yet, so it ranks below community picks.
  • Presented by Oli
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

10K views1 year ago

Software designSoftware architectureDomain-driven designSimplicity and complexity

Oli critiques domain-centric architectures like Hexagonal and Onion, discussing their complexity and trade-offs in real-world software projects.

To separate technical from domain code, architectural approaches like Hexagonal or Onion Architecture are currently all the rage. However, discussions about their semantic details and their mapping to the source code structure of software projects are at least equally ubiquitous.How much abstraction and mapping between architectural concepts is needed? Is persistence metadata in the domain model heresy? Above all: what is the actual goal of the exercise, and: does it have to be so complicated?We address these and other questions in a theoretical overview and by looking at concrete examples. We discuss the trade-offs of different approaches and how various tools and libraries help us to maintain the intended structural integrity.

Why it's here

A top upload from a listed channel

Devoxx is on Hallway's list of conference and university channels, and this upload is one of its most-watched talks or lectures. Nobody has recommended it in the communities yet, so it ranks below community picks.

u/olivergierkein r/softwarearchitecture • Mentions

On “A well-structured layered architecture is already almost hexagonal. I'll prove it with code.”

Pretty much my argument in this talk. Both Hexagonal and Onion-Architecture invert one dependency. That’s it. The rest is cargo-culting detrimental to the IMO more important decomposition of the domain. link to this video

u/olivergierkein r/softwarearchitecture • Mentions

On “The Deception of Onion and Hexagonal Architectures?”

Exactly the arguments I am making in this talk: link to this video

u/olivergierkein r/softwarearchitecture • Mentions

On “How doe modules interact each other in Hexagonal Architecture?”

Likely an unpopular opinion but Hexagonal Architecture should, if at all, be a *secondary* decomposition strategy following the functional decomposition. In contrast to the former, only the latter creates cohesive elements in the codebase, which are crucial for sustainable and cost-effective software maintenance. More details in this talk: link to this video In short: your modules expose APIs and/or publish and consume events which other modules can interact with or listen to. Whether those APIs conform to any secondary decomposition concept is circumstantial.

u/olivergierkein r/softwarearchitecture • Mentions

On “Modularity vs Hexagonal Architecute”

Precisely the core of my talk here: link to this video

u/olivergierkein r/softwarearchitecture • Mentions

On “Is hexagonal architecture good design or just extra layers with better branding? [Manning Giveaway]”

Why Hexagonal et. al. are answers to the wrong question: link to this video