Serverful
Traditional server-based deployment with full control over infrastructure using virtual machines, containers, or bare metal servers for predictable performance.
- VMs & containers
- Bare metal servers
- Virtual Threads
Boundary Control Entity Architecture
Focus on building understandable applications with a strong emphasis on domain logic
Overview
The Boundary-Control-Entity (BCE/ECB) pattern is a software architecture pattern that organizes code into Business Components. A Business Component is a package or namespace comprising three distinct layers, each with specific responsibilities. Business components adhere to the principles of maximal cohesion and minimal coupling, and are named after their domain responsibilities.
Business Component (e.g. "users")
boundary
→
control
→
entity
Business Components
Business components are self-contained modules (also packages or directories) named after their domain responsibilities,promoting maximal cohesion within the component and minimal coupling between components. Each component is organized the same way, comprising boundary, control and entity layers.
Example business component names for a retail shop: checkout, catalog, cart, inventory, pricing, orders, fulfillment, returns, loyalty, customers, notifications, reviews, promotions.
Example: User Management
users
- boundary - REST endpoints, Custom Elements, Lambda function handlers
- control - User validation, authentication logic
- entity - User, Role, Permission models, state management
Example: Order Processing
orderprocessing
- boundary - Order API, checkout interface
- control - Order validation, payment processing
- entity - Order, LineItem, Payment entities
Key Principles
Domain-Driven Naming
Components are named after their business responsibility, not technical concerns
Maximal Cohesion
Related functionality stays together within a single business component
Zero Dependencies
You know when you need it. Make use of existing functionality before reaching out to external resources.
Minimal Coupling
The elements within a given component are more closely related to each other than they are to the elements in other components.
Visual Communication
BCE icons and symbols are available in all major design and drawing tools for consistent architectural documentation
Boundary
The boundary layer serves as the entry point for external actors (users, other systems, schedulers, message brokers, ...), providing appropriate interfaces (REST APIs, GraphQL endpoints, message handlers, Lambda function handlers, web components / custom elements, etc.) depending on the actor type.
- Exposes the functionality of components to users and systems.
- User interfaces and API endpoints
- Input validation and transformation
- Coarse-grained operations
Control
The orchestration layer containing business logic
- Actions / commands
- Stateless procedural logic
Entity
The domain model layer representing core business concepts
- Application data
- Domain objects and data classes
- Business entities
- Persistence mappings
Interaction Rules
Communication patterns between BCE layers follow a strict dependency rule to maintain architectural integrity
Dependency Rule
Direct interactions can only flow in the B → C → E direction
- Boundary → Control: Boundaries delegate business logic to controls
- Boundary → Entity: Boundaries can directly access entities for simple data operations
- Control → Entity: Controls manipulate and orchestrate entities
- Control → Control: Controls within the same component can collaborate
- Entity → Entity: Entities can reference and compose other entities
- Boundary → Boundary: Direct boundary interactions are discouraged; use control layer for orchestration
Reverse Communication
The opposite direction (E → C → B) is only allowed through events
- Entities emit domain events instead of calling controls directly
- Controls publish events rather than invoking boundaries
- Event-driven architecture maintains loose coupling
Cross-Component Communication
- Components interact through their boundary or control layers
- Direct entity access across components is discouraged
- Shared entities can be placed in a common component when needed
Benefits
Clarity
The straightforward structure reflects business concepts. The names of the components and elements are taken directly from the domain concepts.
Maintainability
Changes are localized to specific layers
Testability
Exposed boundaries are tested using system tests/e2e tests, plain facades using integration tests, and sufficiently complex controls or entities using unit tests.
Reusability
'No-ceremony' business logic sharing between components.
Architectural Styles
Complementary architectural styles that can be combined with BCE pattern:
Serverless
Single threaded, thread-per-request configuration for HTTP endpoints and event-driven, asynchronous functions.
- Pay-Per-Use
- Process-Per-Request
- Automatic scaling
- Event-driven execution
Web Components
Standards-based UI development using Custom Elements, Shadow DOM, and ES Modules with minimal tooling and zero framework dependencies.
- Web Standards
- Custom Elements
- Minimal Tooling
- Framework Independent
References and Further Reading
Visual Notation
- UML Robustness Diagrams - Using BCE in analysis and design
- draw.io - (free)
- ArgoUML - (free)
- Visual Paradigm
- Enterprise Architect
- creately
- SVG icons
Origins and Specification
- Entity-Control-Boundary on Wikipedia - Overview and historical context
- Object-Oriented Software Engineering: A Use Case Driven Approach (1992) - Ivar Jacobson's original work introducing the BCE pattern