bce

name

bce

description

Generic, composable architecture rules for the Boundary-Control-Entity (BCE/ECB) pattern — business components, layer responsibilities, package structure, and cross-component relationships. Technology-neutral; meant to be composed with language- or framework-specific skills (e.g. microprofile-server, web-components, aws-cdk, java-cli-app). Use when creating, generating, scaffolding, writing, or reviewing code organized as business components with boundary/control/entity layers. Triggers on "BCE", "ECB", "Boundary-Control-Entity", "business component", "BC layout", "BC structure", "boundary layer", "control layer", "entity layer", or requests to organize, package, refactor, or review code along BCE lines.

Pattern

• structure code using the Boundary-Control-Entity (BCE/ECB) pattern
• the unit of organization is the business component (BC); each BC owns a responsibility and is composed of one or more layers
• the three layers are boundary, control, entity; each has a distinct responsibility (see layer sections below)
• do not explain the BCE pattern in generated documentation

Package / Directory Structure

• package or directory path: [ORGANIZATION].[PROJECT].[BC].[boundary|control|entity]
• the top-level package reflects the application responsibility or name
• business components are direct children of the top-level package and named after their responsibilities
• the boundary, control, entity segments are only allowed inside a business component
• name packages after their domain responsibilities, not technical concerns

Business Components (BC)

• a BC may represent a domain concept or a shared concern; both are valid when the responsibility has a name and is reused
• a BC does not need every layer; a BC may consist of only a control layer when its responsibility is procedural and consumed by other BCs
• not every BC needs a dedicated boundary; control contents may be consumed directly when no facade is justified