This is part of a series, start here!
Created by Ivar Jacobson in 1992 as EIC (Entity-Interface-Control) and renamed by Uncle Bob to Entity-Boundary-Interactor (EBI), It’s a more back-end-focused version of the MVC architecture that came before.
Entity
It consists both of the ‘domain’ entity and all behavior strictly related to it.
So in a very simple example, the ‘Dog’ Entity would hold the data regarding its breed, fur color, health, etc. as well as the logic required for it to behave as expected: a walk function, a bark function, etc.
Already back in ‘92, Jacobson was warning about anemic entities and god objects.
Boundary
The I/O interface of the system.
Think of it as the ‘fence’ of the domain (It’s in the name).
All interaction between your code and the user on one side (GUI, CLI, etc.) and the infrastructure on the other (persistence, event queue, messaging, etc.) should be handled by this guy.
You might want to make it an interface and call it a Port, but that’s still 13 years away.
Interactor
The ones in charge of validating I/O between Boundaries and Entities.
More important than this, they will be managing the interactions between Entities.
In practice, this means that all logic not belonging to or fitting in the Entities will end up here.
In our previous dog example, this role would be taken by the owner. Dogs don’t play dead on their own, the owner (or trainer) needs to give the order.
Stretching the example a bit, dog to dog interaction is usually mediated by one or more humans (assuming they are pets).
The same applies here.
Of course, one interactor will often not be enough. You should end up with about one interactor per use case.
For every abstract operation a user could perform on your system, there should be an interactor ready to handle the use case.