Entity-Control-Boundary

Definition

Pure domain logic, in the form of application independent entities and application specific control objects are separated from dependencies (boundaries) with the outside world.

Note: the control in this pattern is different from the controller in MVC.

How does it work?

The main idea here is to separate domain logic from the rest of the application. Domain logic, the entity and control implements the use cases of the application and does not contain any code that directly talks to the outside world (no ui code, no db code, no file system code, in short, no boundary). This makes the core logic of the system highly reusable in other environments. It is also clear to read and well testable.

• The Entity is a class that represents a business object (Customer, Order, PackagingItem) together with its application-independent business rules.
• The Control object is a class that holds application-specific domain logic. It implements the use cases of the application.
• The Boundary object is a class that contains all logic that deals with external factors, like user interfaces and databases.

Comparing this pattern with MVC, we can say that entities and control objects are the domain-logic part of the Model. The Model, however also contains database specific code and this would be part of the boundary of ECB. The Controller could contain logic from control objects, but mainly it would be part of the boundary. The View would fall completely in the boundary part.

Where does it come from?

It was described in Ivar jacobson's book "Object-oriented software engineering: a use case driven approach"

When should you use it?

• This is the core of modern architectures like hexagonal and clean. It seems to be essential to a large-scale application.

Problems

• Separating domain logic from the rest of the application requires a serious conscious effort and may form a learning curve.

Links

• Wikipedia on Entity-Control-Boundary