Architectural Pattern ECB - JUCSE49-Mavericks/Smart-Class-Routine-Management-System GitHub Wiki

Entity Controller Boundary Architectural Pattern

The Entity Controller Boundary (ECB) pattern is a powerful approach for organizing software architecture, particularly when dealing with event-driven or highly modular systems. This pattern encourages a clean separation of concerns by dividing the system into three main components: Entities, Controllers, and Boundaries.

ECB Explained (Entity-Controller-Boundary)

Entity-Controller-Boundary (ECB) is a software architecture pattern that organizes systems without distinguishing between frontend and backend. It treats all external systems uniformly.

Key Components of Entity-Controller-Boundary:

Entity

  • Holds domain objects (data structures with some behavior).
  • Represents the core data and basic functionality of the system.
  • Encapsulates business rules and logic that are critical to the system's functioning.

Controller

  • Contains application logic, algorithms, and queries.
  • Processes the commands received, applying business rules and coordinating responses.
  • Acts as an intermediary between the entity and boundary, handling interactions and logic.

Boundary

  • Interface between the system and the outside world.
  • Handles external communication, configuration, and connections.
  • May contain API objects, separating them from domain objects to avoid unintended changes.

Layered Structure

  • Outer Layer (Boundary): Communicates with external systems.
  • Middle Layer (Controller): Processes logic and interactions.
  • Inner Layer (Entity): Contains core data structures and business logic.

When to Use the Entity-Controller-Boundary Pattern

The Entity-Controller-Boundary pattern is ideal for:

  • Event-driven systems (e.g., message queues or user actions).
  • Microservices architectures with clear separation between logic and external systems.
  • Highly decoupled systems needing flexible business logic.

How the Entity-Controller-Boundary Pattern Works

Scenario: A Task Management System

Consider a task management system where users can create, edit, and delete tasks. Each of these actions represents a command in the system.

  • Entity: The Task entity represents a task with attributes like title, description, and status. It encapsulates business rules related to tasks.
  • Controller: The TaskController processes the command to create a new task and contains the business logic to handle task creation (e.g., validating input, checking for conflicts, permissions).
  • Boundary: The controller interacts with a TaskRepository interface (the boundary) to store the task in the database, abstracting the persistence details.

Here’s a high-level representation:

In this scenario:

  • The entity represents the core data and business rules.
  • The controller handles the logic and interactions between the entity and boundary.
  • The boundary abstracts the connection to the database.

Benefits of the Entity-Controller-Boundary Pattern

Benefit Description
Separation of Concerns The pattern separates entities, controllers, and boundaries, making the code easier to maintain and test.
Loose Coupling Decouples controllers from external services, enabling easier updates or swaps of components like databases or APIs.
Testability The pattern simplifies unit testing by isolating controllers and boundaries.
Scalability Supports independent scaling of components, allowing controllers and boundaries to evolve separately.
Modularity Components can be developed and deployed independently, improving modularity in large systems.

ECB vs MVC:

Aspect ECB (Entity-Controller-Boundary) MVC (Model-View-Controller)
Layers Entity: Manages core data and database interactions.Controller: Contains business logic and coordinates workflows.Boundary: Handles user inputs and external interactions. Model: Manages data and logic.View: Presents data to the user.Controller: Handles user input and business logic.
ECB introduces extra overhead
Flow (Example)
Why Extra Steps? Separate layers (Boundary and Control) for better organization and maintainability, even for simple tasks. Fewer layers; Controller handles both input and logic directly, making interactions quicker.
Request-Response Flow
Simplicity More detailed, suitable for complex systems needing clear separation. More streamlined, easier to implement, ideal for simpler systems.
Purpose Ensures clear separation of responsibilities, even if it adds steps. Combines responsibilities for faster interactions.
Connection Boundary communicates with Control, which in turn interacts with Entity, without direct access between Boundary and Entity. View is directly connected to both Model and Controller, allowing immediate updates and interactions.
Design Focus Strong encapsulation and reusability of business logic in Control and Entity. Simplified UI and logic maintainability, with faster direct communication.
Use Case Best suited for complex applications requiring clear separation of different layers. Ideal for applications where a quick and straightforward interaction is sufficient.

Conclusion

The Entity-Controller-Boundary pattern offers a scalable, maintainable architecture, especially for event-driven and modular systems. It ensures a cleaner codebase and better adaptability, making it ideal for projects with complex workflows or event handling needs.

References:Entity-Controller-Boundary-Architecture-The-Pattern-to-Structure-Your-Classes