The entity-control-boundary (ECB), or entity-boundary-control (EBC), or boundary-control-entity (BCE) is an architectural pattern used in use-case driven object-oriented programming that structures the classes composing high-level object-oriented source code according to their responsibilities in the use-case realization.
The entity-control-boundary approach finds its origin in Ivar Jacobson's use-case driven object-oriented software engineering (OOSE) method published in 1992.[1] [2] It was originally called Entity-Interface-Control (EIC) but very quickly the term "boundary" replaced "interface" in order to avoid the potential confusion with object-oriented programming language terminology.
It is further developed in the Unified Process, which promotes the use of ECB in the analysis and design activities with the support of UML stereotypes.[3] Agile modelling,[4] [5] and the ICONIX process[6] elaborated on top of ECB architecture pattern with robustness diagrams.[7]
The ECB pattern organises the responsibilities of classes according to their role in the use-case realization:
The corresponding classes are then grouped into service packages, which are an indivisible set of related classes that can be used as software delivery units.
ECB classes are first identified when use-cases are analyzed:
The classes are then refined and re-structured or reorganized as needed for the design, for example:
The ECB pattern assumes that the responsibilities of the classes is also reflected in the relations and interactions between the different categories of classes in order to ensure the robustness of the design.[8] [9]
Robustness diagrams allow to visually represent the relation between entities, controls, boundaries and actors. It uses graphical stereotypes introduced in Jacobson's early work:
| Representation | Relation with | |||||
|---|---|---|---|---|---|---|
| Role | Symbol | Actor | Boundary | Control | Entity | |
| Actor | Yes | Yes | No | No | ||
| Boundary | Yes | Part/whole | Yes | No | ||
| Control | No | Yes | Yes | Yes | ||
| Entity | No | No | Yes | Yes | ||
The following robustness constraints apply:
In principle entities should not know about boundaries and controls. In practice however, some variants allow entities, boundaries and controls to subscribe as observer to an entity.
Similarly, the constraint of a boundary class not knowing about other boundary classes only applies at the highest level, and not between classes that cooperate to implement the same boundary.
There is some similarity between ECB and model–view–controller (MVC): entities belong to the model, and views belongs to boundaries. However the role of the ECB-control is very different from MVC-controller, since it encapsulates also use-case business logic whereas the MVC controller processes user input which would be of the responsibility of the boundary in ECB. The ECB control increases separation of concerns in the architecture by encapsulating business logic that is not directly related to an entity.
The ECB can be used in conjunction with the hexagonal architecture, whenever the boundaries form the outer adapter layer.[10]
ECB is compatible with the clean architecture which merges ECB principles with other architectural design paradigms.[11] [12] Clean architecture places entities at the core, and surround them with a use-case ring (i.e. ECB control) and a ring with gateways and presenters (i.e. ECB boundaries). However, clean architecture requires a one-way dependency from outside to inside, which requires to split ECB controls into use-case logic and object coordination.