How Boundary Control Entity relates to MVC, DDD, Hexagonal, Onion and Clean Architecture
Most layered and "ring" architectures share the same idea: keep the domain independent of the way it is accessed. Boundary Control Entity is an early formulation of this idea. Similar responsibilities recur in later architectures, and Clean Architecture explicitly lists BCE as one of its sources.
Dates mark selected publications and standardization milestones, not necessarily the first use of each approach.
Trygve Reenskaug, Smalltalk at Xerox PARC · Wikipedia
Separates the presentation (view, controller) from the model. Focused on user interfaces.
Relation to BCE: view and controller are boundary responsibilities for human actors; the model corresponds to control and entity.
Ivar Jacobson, "Object-Oriented Software Engineering: A Use Case Driven Approach", based on the Objectory method · Wikipedia
Introduces three object types derived from use cases: interface objects for actor interactions, control objects for use case behavior, entity objects for long-lived information.
Relation to BCE: the origin of the pattern. Later renamed to boundary, control and entity.
Buschmann et al., "Pattern-Oriented Software Architecture, Volume 1" · Wikipedia
Structures a system into horizontal layers, each depending only on the layer below.
Relation to BCE: BCE applies the same dependency rule (B → C → E), but inside each business component instead of across the whole application.
UML 1.1, Profile for Software Development Processes · Wikipedia
The three roles become standard UML stereotypes with the robustness icons used throughout this site.
Relation to BCE: the name "boundary" and the visual notation are standardized.
Doug Rosenberg, Kendall Scott, "Use Case Driven Object Modeling with UML" · Wikipedia
Robustness diagrams bridge use cases and design using boundary, control and entity objects.
Relation to BCE: establishes the interaction rules between the three roles in analysis and design.
Deepak Alur, John Crupi, Dan Malks · Wikipedia
Session Facade, Business Object, Transfer Object and Data Access Object structure enterprise Java applications.
Relation to BCE: the Session Facade is a boundary, business objects are controls and entities. Many of the remaining patterns became obsolete with later Java EE versions.
Martin Fowler, "Patterns of Enterprise Application Architecture" · Service Layer · Domain Model · Wikipedia
A service layer defines the application's boundary and coordinates the domain model.
Relation to BCE: the service layer corresponds to boundary, the domain model to control and entity.
Eric Evans, "Domain-Driven Design" · DDD Reference · Wikipedia
Ubiquitous language, bounded contexts, modules, entities, value objects and aggregates; a layered architecture with user interface, application, domain and infrastructure layers.
Relation to BCE: business components are modules named in the ubiquitous language. DDD entities and value objects live in the entity layer.
Alistair Cockburn · Original article · Wikipedia
The application core communicates with the outside world through ports (interaction contracts). Driving adapters (UI, tests, APIs) call the application, driven adapters (databases, messaging) are called by it. All actors are treated symmetrically.
Relation to BCE: driving adapters correspond to boundaries, the application core to control and entity. Both keep the domain independent of its actors. Hexagonal ports define APIs or protocols; they do not require a separate language-level interface for every port.
Jeffrey Palermo · Original article · Wikipedia
Concentric rings: domain model at the center, surrounded by domain services, application services, and UI, tests and infrastructure on the outside. Dependencies point inward.
Relation to BCE: the rings correspond to entity, control and boundary. Onion Architecture adds explicit dependency inversion for infrastructure.
Robert C. Martin · Original article
The top-level structure of a system should reveal its use cases, not the frameworks it uses.
Relation to BCE: business components named after domain responsibilities are a screaming architecture.
Architecture workshop participants, James Lewis, Fred George · Historical account · Lewis's recorded talk (published 2013) · George's 2012 slides
In May 2011, architects at a workshop near Venice discussed "microservice" as a name for a style they were already exploring. In May 2012, the group settled on "microservices".
James Lewis presented "Microservices — Java, the Unix Way" at 33rd Degree in Kraków in March 2012. Fred George also presented his experience with small, independent services in 2012. These milestones document naming and early presentations, not the invention of the approach.
Relation to BCE: small services can encapsulate business functionality organized internally using boundary, control and entity roles.
Robert C. Martin · Original article · Wikipedia
Entities, use cases (interactors), interface adapters, and frameworks and drivers as concentric circles with inward-pointing dependencies. Explicitly builds on Hexagonal, Onion, Screaming Architecture, DCI and BCE.
Relation to BCE: entities correspond to entity, interactors to control, interface adapters to boundary. Clean Architecture uses "boundary" for the interfaces between the circles.
James Lewis, Martin Fowler · Original article · Wikipedia
Lewis and Fowler describe independently deployable services organized around business capabilities, documenting the characteristics of an already emerging architectural style.
Each service runs in its own process and communicates through lightweight mechanisms, often HTTP APIs. Services can be deployed independently and may use different technologies.
Relation to BCE: business components organize code; microservices introduce process and deployment boundaries. A microservice can host one or more business components, and a business component can be extracted into its own service.
Jimmy Bogard · Original article
Bogard's 2018 article describes an approach he had used for years: organizing code around distinct requests or use cases, minimizing coupling between slices and maximizing coupling within a slice.
Relation to BCE: both organize code by business functionality. A business component can contain several use cases; a vertical slice centers on an individual request or use case. This site's BCE approach gives components a consistent internal structure, while vertical slices can choose their own.
The same responsibilities appear under different names. The mapping is approximate: each architecture draws the lines slightly differently.
| BCE | MVC | Hexagonal | Onion | Clean | DDD |
|---|---|---|---|---|---|
| Business Component | - | Application (hexagon) | - | Component | Module, bounded context |
| Boundary | View, Controller | Driving adapters, driving ports | UI, application services | Interface adapters (controllers, presenters) | User interface, application layer |
| Control | Model | Application core | Domain services | Use cases (interactors) | Domain services |
| Entity | Model | Domain model | Domain model | Entities | Entities, value objects, aggregates |
| Control (outbound integration) | - | Driven ports, driven adapters | Infrastructure | Gateways, frameworks and drivers | Repositories, infrastructure layer |
BCE structures the code by business components first and applies the layers inside each component. Hexagonal, Onion and Clean Architecture are often applied as technical rings at the top level of the application.
Hexagonal Architecture defines interaction contracts at ports; these need not be separate language-level interfaces. Clean Architecture uses dependency inversion where calls cross against the source dependency direction. This site's BCE approach favors concrete classes, introducing interfaces when multiple implementations are needed.
Onion and Clean Architecture point all dependencies towards the domain. BCE allows direct calls from boundary to control to entity; the reverse direction is only allowed through events.
Hexagonal Architecture treats driving and driven actors symmetrically. BCE distinguishes boundaries, which expose functionality to actors, from controls, which integrate external resources.