Software Engineering basics - Entity–Control–Boundary (ECB) Architecture

Entity–Control–Boundary (ECB) Architecture is a use-case–driven architectural pattern introduced by Ivar Jacobson as part of object-oriented analysis and design. The primary objective of ECB is to separate responsibilities clearly among different classes in a system, thereby improving maintainability, clarity, and scalability. It is especially effective during early design phases when translating use cases into object models.

In ECB, Entity objects represent long-lived domain information and business data. These objects encapsulate core business rules and state, such as customer records, orders, or invoices. Entities are independent of user interfaces and workflows, making them reusable and stable even when system behavior changes. They typically map closely to database tables or persistent storage concepts.

Boundary objects act as the interface between the system and external actors, such as users, APIs, or external systems. They handle input validation, formatting, and communication but do not contain business logic. Examples include UI forms, REST controllers, or API gateways. This separation ensures that changes in presentation or communication protocols do not impact core logic.

Control objects coordinate interactions between Boundary and Entity objects. They manage the execution of use cases, enforce workflow logic, and handle sequencing of operations. Control objects are usually short-lived and instantiated per use case or transaction. This layer centralizes behavioral logic, preventing it from being scattered across UI or data classes.

ECB architecture improves separation of concerns, supports cleaner UML diagrams, and makes systems easier to test and evolve. However, it must be applied judiciously, as excessive control classes or over-segmentation can lead to unnecessary complexity if the system is small or simple.