BCE/ECB in the Browser 📎
A Package per Feature and Semantics over Bureaucracy showed BCE in a Java CLI application and claimed the convention is cross-technology. Proof: an events application built with web components and lit-html on plain web standards. No framework, no build; the store is reduction.js, 77 lines on structuredClone, and lit-html is the only runtime dependency. The src directory is a list of BCs:
src ├── creation ├── filter ├── inputs ├── localstorage ├── overview ├── preview └── status
Inside each BC, the fixed names return. The filter component carries all three layers:
filter
├── boundary
│ └── Filter.js
├── control
│ └── FilterControl.js
└── entity
└── FilterReducer.js
The mapping to the browser is direct. The boundary is the custom element: it renders the lit-html view and receives the DOM events, because in a frontend the external actor is the user. The control is a function that creates and dispatches an action. The entity is the state slice with its reducer: state has a home, here it is literally the store.
The dependency direction survives the technology switch: boundary calls control, control updates entity through the store, and the store re-renders the boundary. And layers stay optional: localstorage is control-only, preview is boundary-only.
A Java developer navigates this frontend without learning a new layout, and a frontend developer navigates lightmetal the same way. That is what fixed names buy.