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 — the BCE pattern, also known as Entity Control Boundary (ECB)
Overview
The Boundary-Control-Entity (BCE) pattern, also known as Entity-Control-Boundary (ECB), 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.
For LLMs and AI Agents
BCE gives a code-generating agent a small, fixed vocabulary of places and a short list of settled decisions, which pays off from orientation to review.
Predictable Placement
The path [organization].[project].[bc].[boundary|control|entity]
follows from a component's responsibility, so an agent never invents
structure and different sessions or agents produce the same layout.
One Component, One Context Window
A business component owns one responsibility and typically fits in a single context window, so an agent loads one package instead of the whole tree and keeps the rest of the window for the task. Inside the package, the downward- only dependency rule tells it which layers it can ignore.
Settled Defaults
No interfaces until a second implementation exists, stateless controls, entities that carry behavior, cross-cutting concerns only in the boundary. Each decision made in advance is one fewer place where the model can drift or improvise.
Token Efficiency
An agent spends no tool calls on directory walks or searches to find where things live. The defaults above remove whole files per capability: no interface, no implementation class, no mapper to read or generate. Responsibility-based names carry more meaning per token, since a class name states what it does and where traffic enters. And the rule set itself is a few dozen lines, cheap enough to ride along in every prompt.
Mechanical Reviewability
Dependencies point down, layer names appear only inside a component, and
generic suffixes such as Impl, Service, and
Manager are banned, so compliance is checked with grep-level
effort and violations are findings, not opinions.
One Contract Surface
The boundary is the only entry point for UI, protocols, and system tests, so an agent has exactly one surface to keep stable and exactly one place to test against.
Isolated Changes, Parallel Agents
A change to one capability usually touches one package, so generated diffs stay reviewable and the impact of a mistake is visible from the file list alone. The same isolation lets several agents work on different components at once: their diffs rarely overlap, and they only need to agree on the boundaries between them.
Stack Transfer
The pattern rules are technology-neutral. Stack-specific skills for Java servers, CLIs, web components, and CDK infrastructure specialize them without contradicting them, so an agent's architectural knowledge carries across projects.
The spec-driven sbce workflow builds on these rules: one capability spec maps to one business component of the same name, the boundary is the contract, and "done" is a green test run against it rather than the model's self- assessment. Agent conventions and skills built on BCE are at airails.dev.
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
Java CLI App
Zero-dependency, multi-file Java 25 CLI applications packaged as executable JARs with unnamed classes, modern language features, and no build tool ceremony.
- Zero Dependencies
- Unnamed Classes
- Executable JARs
- Modern Java 25
Static Website
Modern static websites built with semantic HTML and CSS only — no JavaScript, no dependencies, no build system, verified in a real browser.
- Zero JavaScript
- Semantic HTML & CSS
- CSS-Only Interactivity
- Baseline Compliant
AWS CDK
Java AWS CDK v2 infrastructure organized as business components: stacks as boundaries, reusable construct factories as controls, and immutable specs as entities.
- Infrastructure as Code
- Thin Stacks
- Least-Privilege IAM
- Deterministic Synthesis
Java CLI Script
Zero-dependency, single-file Java 25 scripts launched via shebang and installed on the PATH: flat for short scripts, grouped into Boundary, Control, and Entity interfaces as they grow.
- Single File
- Shebang Launched
- Zero Dependencies
- PATH Installed
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
AI-Assisted Development
- airails.dev - Agentic AI development conventions and skills based on BCE architecture
- sbce.dev - Spec-Driven BCE: one capability spec per business component, the spec is the boundary contract
Origins and Specification
- Entity-Control-Boundary on Wikipedia - Overview and historical context
- Coupling (computer programming) on Wikipedia - Degree of interdependence between software modules
- Object-Oriented Software Engineering: A Use Case Driven Approach (1992) - Ivar Jacobson's original work introducing the BCE pattern
- airhacks.fm #259: How Boundary Control Entity, UML and Components Happened
- Timeline - How BCE relates to MVC, DDD, Hexagonal, Onion and Clean Architecture