What are some common anti-patterns that appear when Hexagonal Architecture is applied across a larger codebase or multiple teams, beyond simple leaky ports, and how do they undermine the pattern's intent?

## How the failure modes shift at scale Once Hexagonal Architecture moves from a single well-scoped module to a multi-team, multi-service codebase, its failure modes shift from "did we draw the boundary at all" to "did we draw the boundary at the right granularity and for the right reason," and several recurring anti-patterns show up predictably at that scale. ## Port explosion Port explosion is the most common: a team, in the name of following the pattern strictly, defines a separate single-method interface for every distinct call the core makes outward — a `SaveOrderPort`, a `FindOrderByIdPort`, a `FindOrdersByCustomerPort`, a `DeleteOrderPort` — rather than one cohesive `OrderRepository` port grouping the related operations. The result is dozens or hundreds of tiny interface files for what should be a handful of coherent capabilities, and navigating the codebase now requires jumping through more indirection than the plain framework-coupled code it replaced, inverting the pattern's intended readability benefit. This tends to emerge when teams treat "one port per capability" as "one port per method" without a shared sense of what counts as a cohesive capability — a judgment call that benefits from explicit team convention, such as grouping ports around aggregate boundaries rather than around individual queries. ## The god port The inverse failure is the "god port": one sprawling interface covering many unrelated responsibilities, such as a single data-access port with fifty methods spanning orders, customers, and inventory, or a notification port that handles email, SMS, and push notifications all in one contract. This reintroduces the exact coupling ports are meant to avoid: - any test needing even one method from the god port must supply a fake implementing all fifty; - any change to one unrelated method risks breaking every consumer's mock setup; - swapping just the email implementation for a different vendor is impossible without touching everything else bundled into the same interface. It tends to emerge from teams retrofitting hexagonal boundaries onto an existing monolithic service class by mechanically wrapping it in one interface, rather than actually decomposing responsibilities along the lines the ports are meant to express. ## Anemic ports Anemic ports are a subtler and arguably more damaging anti-pattern at scale: a port whose method names and shapes mirror generic CRUD operations — `findById`, `save`, `deleteById`, `findAll` — rather than the business operations the core actually needs. On the surface this looks compliant, since it is technically an interface, technically implemented by an adapter, but it means the core, not the port, ends up doing the work of assembling multi-step consistency guarantees out of primitive CRUD calls, because the port never captured the actual business operation as a first-class contract. At scale, this compounds: dozens of core services all reach for generic save/find primitives on their repositories, nobody's port encodes any actual business invariant, and the supposed ports-and-adapters codebase behaves, in practice, exactly like a plain layered CRUD system wearing hexagonal clothing. ## Fake hexagonal "Fake hexagonal" is the organizational version of the problem: leadership mandates hexagonal architecture as a blanket standard across all services, so every team writes ports and adapters, but in the overwhelming majority of modules there is, was, and will only ever be exactly one implementation per port — no test double is used, tests hit a real test database directly instead — no second adapter is ever added, and the interfaces exist purely because a checklist requires them. This is expensive in aggregate: across dozens of services and hundreds of engineers, the navigation and maintenance tax of unused indirection compounds into a real productivity cost, without a single instance of the flexibility payoff the pattern is meant to buy — precisely the scenario a selective-adoption strategy warns against, just realized at organizational scale rather than in one module. ## The underlying lesson The underlying lesson across all four anti-patterns is that Hexagonal Architecture's value comes from the **SHAPE** of the boundary matching real business capabilities and real variability, not from the mechanical presence of interfaces. A principal-level response to these failure modes at scale isn't a rule like "always use ports" or "never use ports" but a small number of concrete, checkable conventions: 1. group ports around aggregate/capability boundaries, not individual methods or entire subsystems; 2. require ports to express business operations, not CRUD primitives, wherever an invariant spans more than one write; 3. require an explicit, revisited justification, real multiple adapters or a real testing/isolation need, before a new module adopts full ports-and-adapters discipline, rather than applying it by default. Some organizations enforce part of this with automated architecture-boundary checks confirming core packages have zero adapter/framework imports, combined with periodic review of port shapes themselves, since the import-boundary rule alone catches leakage but not port-explosion, god-port, or anemic-port problems, which are shape/design issues no automated rule fully catches.