How Hexagonal, Onion and Clean Architecture Map to BCE 📎
MVC, DDD, Hexagonal, Onion and Clean Architecture all keep the domain independent of the way it is accessed. The BCE timeline lists the milestones and maps each architecture to BCE: bce.design/timeline.html.
Selected milestones:
- 1979, MVC (Trygve Reenskaug): view and controller are boundaries, the model maps to control and entity.
- 1992, OOSE (Ivar Jacobson): interface, control and entity objects derived from use cases. Interface objects were later renamed to boundary.
- 1997, UML 1.1:
«boundary»,«control»and«entity»become standard stereotypes. - 2003, DDD (Eric Evans): business components are modules named in the ubiquitous language. DDD entities and value objects belong in the entity layer.
- 2005, Hexagonal (Alistair Cockburn): driving adapters map to boundaries, the application core to control and entity.
- 2008, Onion (Jeffrey Palermo): the rings map to entity, control and boundary.
- 2012, Clean Architecture (Robert C. Martin): explicitly lists BCE as one of its sources. Clean Architecture uses "boundary" for the interfaces between its circles, not for the layer facing the actors.
- 2014, Microservices (James Lewis, Martin Fowler): a microservice hosts one or more business components.
- 2018, Vertical Slices (Jimmy Bogard): a slice centers on a single request, a business component groups several use cases.
All of them keep the domain independent of the way it is accessed. The differences are in the details:
- BCE structures the code by business components first and applies boundary, control and entity inside each component. Hexagonal, Onion and Clean Architecture are often applied as technical rings at the top level of the application.
- BCE uses concrete classes and introduces interfaces only when there are multiple implementations. Hexagonal ports are interaction contracts and do not require a Java interface per port.
- Boundaries call controls, controls call entities. Calls in the opposite direction are allowed only through events.
- Hexagonal Architecture treats driving and driven actors symmetrically. In BCE, boundaries expose functionality to actors, while controls integrate external resources.
Reference: bce.design. The story behind BCE: airhacks.fm #259: How Boundary Control Entity, UML and Components Happened.
The /sbce skill applies BCE to spec-driven development: one capability spec per business component, with the spec as the boundary contract. Details: sbce.dev.
Free course on airhacks.io: "BCE: The Screaming Architecture For Humans and LLMs".