Oliver Drotbohm argues that hexagonal and onion architectures, while well-intentioned, are answers to a 20-year-old problem: making domain code testable in isolation when deploying to application servers was painful. Today, with test containers and modern tooling, that rationale is weaker. Both architectures are essentially layered architecture with an inverted dependency arrow, and they fail to provide guidance on functional decomposition. The real goal of software design is creating units of strong cohesion that are loosely coupled. Technical package structures (controllers, services, repositories) produce low cohesion, scattering related business logic across folders. The recommended approach is to organize code by vertical business slices first, hide internals by default using Java visibility, and let the complexity of each slice determine how much internal technical decomposition is warranted. He also introduces Spring Modulith and the jMolecules project as tools to express architectural stereotypes in code without relying on package names as the sole organizational mechanism.
Sort: