EBI Architecture

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

The Entity-Boundary-Interactor (EBI) Architecture has been made known by Robert C. Martin in his talks about Clean Architecture (of which I will talk in a later post).

However, this pattern was published by Ivar Jacobson back in 1992, in his book Object-Oriented Software Engineering: A use case driven approach. At the time, Jacobson actually called it Entity-Interface-Control, but the name was changed so that “Interface” would not be confused with the “Interface” language construct (which some languages don’t even have) nor with “User Interface”, and “Control” would not be confused with the MVC Controller.

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:

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“.

Boundary (Interface)

The Boundary objects model the interface with the system.

[…] everything concerning the interface of the system is placed in an interface object

Ivar Jacobson 1992, pp. 134

All functionality dependent on the system environment (tools and delivery mechanisms) belongs in the Boundary objects.

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.

fig_7_14_boundaries — Ivar Jacobson 1992, pp. 171

Reflecting on this concept of Boundary, looking at figure 7.14 and imagining it with 6 boundaries instead of 4, I can’t avoid connecting it to the Ports & Adapters Architecture (which I will talk about in a later post) published in 2005, 13 years later!

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 objects

Ivar Jacobson 1992, pp. 185

This means that all behaviour that does not fit into a boundary or Entity will be placed in one or several control objects.

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.

Why 3 object types?

At that time, Jacobson says, other OO methodologies would put all of those responsibilities in the entity itself, however, he (and his collaborators) preferred segregating those responsibilities into 3 object types because it would make the system more adaptable to changes.

[…] all systems will change. Therefore stability will occur in the sense that all changes will be local, that is, affect (preferably) only one object in the system.

Ivar Jacobson 1992, pg. 135

The objective is thus, to have locality in changes of the system, by encapsulating responsibilities. If we think about this, Jacobson is implicitly talking about the Single Responsibility Principle which was published 10 years later by Robert C. Martin in his wonderful book “Agile Software Development, Principles, Patterns, and Practices“.

Conclusion

The same way in the MVC pattern the Model represents the whole back-end, all the entities, services and their relations, the EBI pattern sees the Boundary as one complete connection to the outside world and not just a view, a controller or an interface (the language construct). The Boundary represents the whole presentation layer which in MVC corresponds to the View and the Controller. The Entity in EBI stands for actual Entities who hold data end their associated behaviour, while the Interactor objects make the connection between the presentation layer and the Entities, they are what I would call Application Services and Domain Services.

The EBI pattern is to the back-end what MVC is to the front-end. They are not an alternative to each other, they are complementary. If we would put them together in a single pattern we could call it something like View-Controller-Interactor-Entity.