The silent base of modern Software Architecture.

Created by Ivar Jacobson in 1992 as EIC (Entity-Interface-Control) and reborn by Uncle Bob as Entity-Boundary-Interactor to avoid ambiguous terms (because having two names for the same concept isn’t confusing at all).

These ideas are a ‘level up’ of sorts of the ones in MVC architecture, although this approach is more suited for server side/back end development than MVC-MVVM.

Not all business rules are created equal

There’s an important distinction to make in regard to business rules, often pointed out by Uncle Bob when approaching this subject.

We can observe two distinct types of business rules based on their relationship with the Business itself (as in the actual Business, the legal entity the software is made for):

• Application Independent Rules: The ones that owe their existence to the Business itself. These consist of what the Business is or does, they would be the same with or without computers.
• Application Specific/Dependent Rules: The ones that owe their existence to the automation of the previously mentioned rules. This is what the Business needs from the software, they depend on the software existing and on programmers developing them.

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 explicitly avoiding anemic entities.

We can take this a step further and say that this piece of the puzzle contains the Application Independent Business Rules, the basic logic and behavior required by the Business.

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 side/infrastructure (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 the Boundaries and the 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.

Here we will find the Application Specific/Dependent Rules.

Of course, one interactor will often not suffice. You should end up with more or less 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.

That might sound like an Application Service, but they are not quite the same.