bce

Name: bce
Author: AdamBien

40stars10forks

How to install bce?

adambien/airails/bce

$npx -y skills add AdamBien/airails --skill bce

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	## Pattern
2
3	- structure code using the Boundary-Control-Entity (BCE/ECB) pattern
4	- the unit of organization is the business component (BC); each BC owns a responsibility and is composed of one or more layers
5	- the three layers are boundary, control, entity; each has a distinct responsibility (see layer sections below)
6	- do not explain the BCE pattern in generated documentation
7
8	## Package / Directory Structure
9
10	- package or directory path: `[ORGANIZATION].[PROJECT].[BC].[boundary\|control\|entity]`
11	- the top-level package reflects the application responsibility or name
12	- business components are direct children of the top-level package and named after their responsibilities
13	- the `boundary`, `control`, `entity` segments are only allowed inside a business component
14	- name packages after their domain responsibilities, not technical concerns
15
16	## Business Components (BC)
17
18	- a BC may represent a domain concept or a shared concern; both are valid when the responsibility has a name and is reused
19	- 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
20	- not every BC needs a dedicated boundary; control contents may be consumed directly when no facade is justified
21	- prefer a dedicated BC over the root application package when a shared concern carries domain or protocol semantics, exposes more than one operation, or is expected to grow
22	- reserve the root application package for trivial single-class plumbing with no business semantics and no protocol coupling
23	- create new BCs with minimal logic and essential fields only
24
25	## Boundary Layer
26
27	- keep coarse-grained classes in the boundary
28	- place facades that adapt external protocols, transports, or UI events to internal operations in the boundary
29	- boundary classes are the only entry points called from outside the system; external actors (UI, protocols, transports, tests) never reach control or entity directly
30	- cross-cutting concerns that wrap an operation (transactions, authorization checks, request/response mapping) belong in the boundary, not in control or entity
31
32	## Control Layer
33
34	- implement procedural business logic in the control layer
35	- prefer stateless, function-like units for procedural logic
36	- control may be called by the boundary of the same BC or directly by other BCs; the boundary is not a gate for cross-BC calls
37
38	## Entity Layer
39
40	- maintain domain objects, data classes, and entities in the entity layer
41	- entities maintain state and corresponding behavior; they are not anemic data holders
42	- model value objects as enums or equivalent closed sets where the language supports them
43	- direct references between entities from independent BCs are allowed, but always aim for Maximal Cohesion and Minimal Coupling between BCs
44	- if a relation exists in the persistent store (e.g. foreign key), the entities must carry a corresponding reference (id field or association); the schema is the source of truth
45	- excessive cross-BC references or shared configuration is a refactoring signal — split, merge, or rebalance the BCs to restore cohesion
46
47	## Naming
48
49	- name classes, modules, and files after their responsibilities
50	- avoid meaningless suffixes (e.g. `Impl`, `Service`, `Manager`, `Creator`)
51	- a class or module name must not end with `Control`
52	- reserve protocol- or pattern-specific suffixes (e.g. `Resource`, `Factory`, `Builder`) for elements that actually fulfill that role
53
54	## Documentation
55
56	- document only domain-specific packages where the purpose is not self-evident
57	- when documenting a top-level package or BC, describe design decisions and responsibilities — not contents
58	- in Java, use `package-info.java` with JavaDoc to document packages
59	- do not write documentation that restates the BCE pattern itself
60
61	## Composition with Other Skills
62
63	- this skill defines only the architectural pattern; language, framework, build, testing, and protocol rules come from the composed skill (e.g. `microprofile-server`, `web-components`, `aws-cdk`, `java-cli-app`)
64	- when a composed skill adds a layer rule (e.g. "health checks belong in boundary", "JAX-RS resources are boundary classes"), apply it on top of the BCE rules above; the composed skill always specializes, never cont

People who liked this also viewed

6 picks

Type

bce

40stars10forks

View on GitHub

How to install bce?

adambien/airails/bce

$npx -y skills add AdamBien/airails --skill bce

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Pattern
2
3	- structure code using the Boundary-Control-Entity (BCE/ECB) pattern
4	- the unit of organization is the business component (BC); each BC owns a responsibility and is composed of one or more layers
5	- the three layers are boundary, control, entity; each has a distinct responsibility (see layer sections below)
6	- do not explain the BCE pattern in generated documentation
7
8	## Package / Directory Structure
9
10	- package or directory path: `[ORGANIZATION].[PROJECT].[BC].[boundary\|control\|entity]`
11	- the top-level package reflects the application responsibility or name
12	- business components are direct children of the top-level package and named after their responsibilities
13	- the `boundary`, `control`, `entity` segments are only allowed inside a business component
14	- name packages after their domain responsibilities, not technical concerns
15
16	## Business Components (BC)
17
18	- a BC may represent a domain concept or a shared concern; both are valid when the responsibility has a name and is reused
19	- 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
20	- not every BC needs a dedicated boundary; control contents may be consumed directly when no facade is justified
21	- prefer a dedicated BC over the root application package when a shared concern carries domain or protocol semantics, exposes more than one operation, or is expected to grow
22	- reserve the root application package for trivial single-class plumbing with no business semantics and no protocol coupling
23	- create new BCs with minimal logic and essential fields only
24
25	## Boundary Layer
26
27	- keep coarse-grained classes in the boundary
28	- place facades that adapt external protocols, transports, or UI events to internal operations in the boundary
29	- boundary classes are the only entry points called from outside the system; external actors (UI, protocols, transports, tests) never reach control or entity directly
30	- cross-cutting concerns that wrap an operation (transactions, authorization checks, request/response mapping) belong in the boundary, not in control or entity
31
32	## Control Layer
33
34	- implement procedural business logic in the control layer
35	- prefer stateless, function-like units for procedural logic
36	- control may be called by the boundary of the same BC or directly by other BCs; the boundary is not a gate for cross-BC calls
37
38	## Entity Layer
39
40	- maintain domain objects, data classes, and entities in the entity layer
41	- entities maintain state and corresponding behavior; they are not anemic data holders
42	- model value objects as enums or equivalent closed sets where the language supports them
43	- direct references between entities from independent BCs are allowed, but always aim for Maximal Cohesion and Minimal Coupling between BCs
44	- if a relation exists in the persistent store (e.g. foreign key), the entities must carry a corresponding reference (id field or association); the schema is the source of truth
45	- excessive cross-BC references or shared configuration is a refactoring signal — split, merge, or rebalance the BCs to restore cohesion
46
47	## Naming
48
49	- name classes, modules, and files after their responsibilities
50	- avoid meaningless suffixes (e.g. `Impl`, `Service`, `Manager`, `Creator`)
51	- a class or module name must not end with `Control`
52	- reserve protocol- or pattern-specific suffixes (e.g. `Resource`, `Factory`, `Builder`) for elements that actually fulfill that role
53
54	## Documentation
55
56	- document only domain-specific packages where the purpose is not self-evident
57	- when documenting a top-level package or BC, describe design decisions and responsibilities — not contents
58	- in Java, use `package-info.java` with JavaDoc to document packages
59	- do not write documentation that restates the BCE pattern itself
60
61	## Composition with Other Skills
62
63	- this skill defines only the architectural pattern; language, framework, build, testing, and protocol rules come from the composed skill (e.g. `microprofile-server`, `web-components`, `aws-cdk`, `java-cli-app`)
64	- when a composed skill adds a layer rule (e.g. "health checks belong in boundary", "JAX-RS resources are boundary classes"), apply it on top of the BCE rules above; the composed skill always specializes, never cont

People who liked this also viewed

6 picks

Type