Shared Kernel Standard¶
Executive Summary¶
Shared Kernel Standard defines what may live in shared code. The shared kernel must remain minimal and must not become a dumping ground for business behavior.
Allowed Shared Kernel Contents¶
| Allowed | Examples |
|---|---|
| Identifiers | TenantId, OrganizationId, UserId, CorrelationId, EventId. |
| Universal value types | Money, percentage, date range where truly domain-neutral. |
| Metadata primitives | Audit metadata, event metadata, actor reference. |
| Technical results | Generic result and error primitives without business rules. |
| Common annotations or markers | Only where stable and architecture-approved. |
Forbidden Shared Kernel Contents¶
| Forbidden | Reason |
|---|---|
| Domain aggregates | Belong to owning modules. |
| Domain services | Business behavior belongs to owning Domains. |
| Repositories | Persistence ownership is module-local. |
| Workflow orchestration | Practices and Domains own process behavior. |
| Integration logic | Belongs behind integration boundaries. |
| AIOS prompts or tools | Belong to Intelligence or governed AIOS boundaries. |
Review Rule¶
Shared kernel additions require architecture review when they introduce a new concept, behavior, dependency, or business meaning.