Modèle Entity-Boundary-Interactor
L' « Entity-Control-Boundary (ECB) » ou « Entity-Boundary-Control (EBC) », ou « Boundary-Control-Entity (BCE) », qui pourrait être traduit en français par « Entité-Contrôle-Frontière », est un patron d'architecture utilisé pour la conception de logiciels orientés objet. Il vise à structurer les classes selon leurs responsabilités dans la mise en œuvre de cas d'utilisations. The Entity-Boundary-Interactor (EBI) Architecture has been made known by Robert C. Martin in his talks about Clean Architecture .
Entity
The Entity objects hold the data used by the system and all the behaviour naturally coupled to this data. Each Entity object represents a concept relevant to the problem domain and wich holds identity and resilient (persistent) data. Jacobson tells us that an Entity object should contain the logic that would change when the Entity itself changes, ie. if the data structure it holds changes, the operations on that data will also need to change and therefore they should be located in the Entity as well.
It is interesting to note a warning that Jacobson makes, already back in 1992:
It is interesting to note a warning that Jacobson makes, already back in 1992:
Beginners may sometime only use entity object as data carriers and place all dynamic behaviour in control objects […]. This should, however be avoided. […] Instead, quite a lot of behaviour should be placed in the entity objects.
Ivar Jacobson 1992, pp. 134
This is a warning against what we, now, know as “anaemic entities“.
Any interaction of the system with an actor goes through a Boundary object. As Jacobson describes, an actor can be a human user like a customer or an administrator (operator), but it might also be a non-human “user” like an alarm, a printer, or a third party API.
Sutch behaviour consists typically of operations over several Entities, culminating in returning some result to a boundary object.
Therefore, Jacobson thinks of Control objects not only as the objects that orchestrate a use case but also as any object that has behaviour relevant for a use case but is not a Boundary nor an Entity.
Comparing with my experience, I would say that he calls interactors to what I call Application Services (who orchestrate use cases) and Domain Services (who contain Domain behaviour but are not entities).
Boundary (Interface)
The Boundary objects model the interface with the system.[…] everything concerning the interface of the system is placed in an interface objectAll functionality dependent on the system environment (tools and delivery mechanisms) belongs in the Boundary objects.
Ivar Jacobson 1992, pp. 134
Any interaction of the system with an actor goes through a Boundary object. As Jacobson describes, an actor can be a human user like a customer or an administrator (operator), but it might also be a non-human “user” like an alarm, a printer, or a third party API.
Interactor (Control)
The Interactor objects will hold behaviour not naturally tied to any of the other types of objects.Sutch behaviour consists typically of operations over several Entities, culminating in returning some result to a boundary object.
Behaviour that remains after the Interface objects and Entity objects have obtained their parts will be placed in the control objectsThis means that all behaviour that does not fit into a boundary or Entity will be placed in one or several control objects.
Ivar Jacobson 1992, pp. 185
Therefore, Jacobson thinks of Control objects not only as the objects that orchestrate a use case but also as any object that has behaviour relevant for a use case but is not a Boundary nor an Entity.
Comparing with my experience, I would say that he calls interactors to what I call Application Services (who orchestrate use cases) and Domain Services (who contain Domain behaviour but are not entities).
The reason why this intermediary Interactor objects are very important is that if we don’t use them, we will put their specific use case logic in the Entities. However, Entities are used in several use cases and they have, therefore, generic usage. By putting specific use case logic in an Entity, we make it available in several Boundaries, who might end up using it as if it was a generic logic and we might end up changing it to adjust it to another Boundary, increasing its complexity and the chance of breaking the other use cases where it is used.
Ressources
- https://herbertograca.com/2017/08/24/ebi-architecture/
Commentaires
Enregistrer un commentaire