BCE (Boundary-Control-Entity) architecture defines strict dependency rules within and between business components. Inside a component, dependencies flow downward: boundary to control to entity, or boundary to entity directly. Entities never depend upward — they emit events instead. Between components, control-to-control and entity-to-entity calls are allowed and direct, while boundary-to-boundary calls should be avoided. A useful heuristic: if a component communicates more with neighbors than with itself, it was split incorrectly.
Questions this post answers
In BCE architecture, can an entity call a control or boundary?
No. In BCE, entities must never call upward to controls or boundaries. If an entity needs something from a higher layer, it emits an event instead. Any layer of any component can process that event, keeping the entity unaware of the receiver. This preserves the downward-only dependency direction within a business component. Developers designing BCE components track architectural patterns like this on daily.dev.
In BCE architecture, can one business component's control call another component's control directly?
Yes, control-to-control calls between business components are allowed and direct — no interfaces are required in between. In Quarkus and MicroProfile applications, the target control is simply injected. Boundary-to-boundary calls between components should be avoided, as boundaries are designed for external actors, not for inter-component communication. Teams adopting BCE across services find related architecture discussions on daily.dev.