Rayk Lucid Toolkit Manage Architecture

↑ Parent: [link] | ← Siblings: [links] | ↓ Children: [links]

Overview

[High-level purpose and scope]

Structural Components

Atoms

[Pure functions, immutable objects, leaf nodes]

Composites

[Containers that orchestrate Atoms]

Conduits

[Boundaries between Deployable Units - Protocol Buffers, versioned]

Deployable Units

[Services with focused scope, idempotent operations]

Data Strategy

Internal Models

[Single Subject Data Types - minimal, focused]

Boundary Semantics

[Schema.org types at API edges]

Architectural Rules

[Constraints table: Dependencies, Data State, Protocol, etc.]

Decision Records

[Links to ADRs]

</template>
</quick_start>

<core_principles>
<composition_over_inheritance>
Behavior is never inherited—it is composed. If an object needs functionality, it must contain a component that provides it. Systems are assembled like machinery: swap the engine without changing the chassis.

**Rule**: No inheritance for behavior. Use composition exclusively.
</composition_over_inheritance>

<radical_containment>
The "Air-Gap Principle": Modules operate under assumption of hostility.

- **Failure Containment**: Sub-module crashes stay within their boundary
- **Scope Isolation**: Variables and logic invisible unless explicitly exposed via Conduit

**Rule**: Failures never propagate upward. Boundaries are strict.
</radical_containment>

<functional_immutability>
- **Immutable by Default**: Data never mutated in place; create new versions
- **Pure Transformations**: Components as pipelines (Input → Transformation → Output)
- **Side Effects at Boundaries**: I/O pushed to system edges

**Enforcement Libraries**:
- Dart/Flutter: `fpdart`, `freezed`
- Python: `returns`, `immutables`
- TypeScript: `fp-ts`, `immer`
</functional_immutability>

<simplicity_vs_performance>
**Default (80%)**: Generic simplicity—standard list processing, readable transformations

**Performance Tunnel (20%)**: When profiling proves bottleneck, tunnel through abstraction for low-level optimization (memory arenas, bit-masking, zero-copy buffers). Always encapsulate behind standard interface.
</simplicity_vs_performance>
</core_principles>

<structural_anatomy>
<atom>
**The Leaf Node** - Smallest unit of architecture

- Pure functions or immutable objects
- Highly testable
- Where "Performance Tunnel" code lives
- Exposes simple interface regardless of internal complexity

Example: Complex math model in Rust exposing `calculate(input)` interface
</atom>

<composite>
**The Container** - Structural glue

- Does NOT perform business logic—orchestrates Atoms
- Routes data from Atom A to Atom B
- Generic across business domains
- Manages lifecycles and dependencies
</composite>

<conduit>
**The Distributable Boundary** - Between Deployable Units

- Location transparency (network/process boundaries)
- **Protocol Buffers mandatory** for definition
- **Explicitly versioned** (e.g., `v1.PricingService`)
- Enables split/async deployments

Example: `v1.PricingService` → `v2.PricingService` supports old consumers
</conduit>

<deployable_unit>
**The Service** - Runtime manifestation

- Focused scope on specific domain capability
- **Idempotent by Default**: Retrying operations must be safe
- Contains hierarchy of Composites and Atoms
- Is the "Host" for composition
</deployable_unit>
</structural_anatomy>

<data_strategy>
<graph_modeling>
Data as interconnected entities, not rigid tables. Relationships are first-class citizens.

**Apply to**: Relational DB, Graph DB, or in-memory—domain model reflects graph structure.
</graph_modeling>

<boundary_semantics>
At system edges (external APIs, AI agents, LLMs):

- **Schema.org as lingua franca**: Self-describing to automated consumers
- **Serialization**: JSON-LD or Protobuf maps
- **Extensions**: Use standard extension mechanisms, never proprietary root types
</boundary_semantics>

<internal_models>
Inside the air-gap:

- **Single Subject Data Types**: Minimal structures for specific pure functions
- **No Schema.org bloat internally**: Internal types optimized for computation
- **Mapping Layer**: Pure functions transform internal types → Schema.org at egress
</internal_models>
</data_strategy>

<documentation_hierarchy>
<three_tier_abstraction>
**Platform Level** (architecture/)
↓ describes intent, contracts, cross-cutting concerns

**Repository Level** (individual repos)
↓ describes implementation patterns, internal structure

**Component Level** (apps, services, packages)
↓ describes specific modules, APIs, data flows

**Abstraction Principle**: Each level answers questions appropriate to its scope. When describing implementation details at the platform level, you've gone too deep—link to the child document instead.
</three_tier_abstraction>

<document_type_hierarchy>
| Pattern | Role | Trust Level |
|---------|------|-------------|
| `README.md` | Navigation index, entry point | Meta |
| `ARCHITECTURE.md` | Root architecture (uppercase = authoritative) | Highest at level |
| `architecture.md` | Child architecture (lowercase = inherits context) | Inherits from parent |
| `{topic}.md` | Focused topic document | Scoped to topic |
| `adr-NNN-{slug}.md` | Decision record | Historical record |
</document_type_hierarchy>

<platform_documents>
Top-level platform documentation structure:

| Document | Purpose |
|----------|---------|
| `README.md` | Governance model, naming conventions, navigation index |
| `platform-overview.md` | Executive summary, project map, deployment context (30,000 ft view) |
| `shared-concepts.md` | Domain entities, semantic vocabulary, glossary (the nouns) |
| `communication-protocols.md` | Transport protocols, serialization, message structures (the verbs) |
| `integration-patterns.md` | End-to-end flows, cross-boundary interactions |
| `data-residency.md` | Storage boundaries, sync patterns, privacy, data locality |
| `cross-cutting-concerns.md` | Auth, security, observability, error handling |
| `decisions/` | ADR directory (append-only history) |
</platform_documents>

<reading_paths>
**For understanding the platform:**
`platform-overview.md` → `shared-concepts.md` → `communication-protocols.md` → `integration-patterns.md`

**For implementing a feature:**
Platform doc → Repository `ARCHITECTURE.md` → Component `architecture.md`

**For understanding past decisions:**
`decisions/adr-NNN-*.md`
</reading_paths>

<levels>
| Level | Scope | File |
|-------|-------|------|
| Platform | Cross-cutting concerns, architectural vision | `ARCHITECTURE.md` (root) |
| Repository | Specific codebase scope and context | `architecture.md` |
| Application/Service | Service-specific logic and boundaries | `{service}/architecture.md` |
| Component | Deep implementation details | `{component}/architecture.md` |
</levels>

<navigation>
Every architecture document includes navigation headers:

```markdown
↑ Parent: ../ARCHITECTURE.md
← Siblings: ../auth-service/architecture.md, ../billing-service/architecture.md
↓ Children: ./components/cache.md, ./components/validator.md

Creates traversable graph for both humans and AI assistants.

• [*Needs Resolution] - Requires decision
• [*Needs More Depth] - Requires elaboration
• [*Needs Verification] - Requires validation

External[External Consumer] --> C1
C1 --> A1
A1 --> A2
A2 --> A3

</component_diagram>

<data_flow>
```mermaid
flowchart LR
    subgraph "Internal (Air-Gap)"
        SST[Single Subject Types]
        PF[Pure Functions]
    end

    subgraph "Boundary"
        ML[Mapping Layer]
        SO[Schema.org Types]
    end

    Input --> SST
    SST --> PF
    PF --> ML
    ML --> SO
    SO --> Output

Result: Split deployments work; new producer supports old consumers.

• Hierarchy level correctly identified (Platform/Repo/Service/Component)
• Navigation headers present (↑ ← ↓)
• Maturity status declared
• Structural components documented (Atoms, Composites, Conduits, Units)
• Data strategy defined (internal types, boundary semantics)
• Architectural rules table included
• Diagrams scoped to current level only
• Quality markers resolved or documented
• Related ADRs linked

• references/component-patterns.md - Atom, Composite, Conduit implementation patterns
• references/data-modeling.md - Schema.org integration, Single Subject Types
• references/documentation-templates.md - Complete templates by hierarchy level

LCA Core Principles (this plugin)
    ↓ CANNOT be overridden, only adopted/extended
Platform ARCHITECTURE.md
    ↓ CANNOT be overridden by lower levels
Repository architecture.md
    ↓ CANNOT be overridden by lower levels
Service/Component architecture.md
    ↓ Most specific, applies to local code

Closer to code = applies to code, but CANNOT override higher levels.

• Extend: Add detail not specified above

  • Platform: "Use Protocol Buffers" → Service: "Use proto3 with buf validation"

• Elaborate: Provide implementation specifics

  • Platform: "Services must be idempotent" → Service: "Via request-id deduplication"

• Specialize: Apply general rules to specific context

  • Platform: "Schema.org at boundaries" → Service: "Schema.org/Order for orders API"

• Override: Contradict a higher-level decision

  • ❌ Platform: "No inheritance" → Service: "Use inheritance for code reuse"

• Relax: Weaken a constraint from above

  • ❌ Platform: "All APIs versioned" → Service: "Internal APIs skip versioning"

• Ignore: Omit required elements from above

  • ❌ Platform requires Data Strategy → Service omits section entirely

1. Composition over Inheritance - No behavior inheritance
2. Radical Containment - Failures contained within boundaries
3. Functional Immutability - Data immutable by default
4. Protocol Buffers for Conduits - Boundaries use protobufs
5. Schema.org at Boundaries - External APIs use Schema.org
6. Single Subject Types Internally - Internal types are minimal
7. Versioned Conduits - API boundaries are versioned
8. Uni-directional Dependencies - No circular dependencies

Project architecture may adopt and extend these principles but never contradict them.

Use /architect:review to run consistency checks across hierarchy.

• Structural hierarchy is clear (what contains what)
• Boundaries are explicit (where Conduits exist)
• Data flow is documented (internal → boundary transformation)
• Maturity status reflects actual review state
• Navigation enables traversal to related documents
• Diagrams support understanding without creating visual complexity
• Hierarchy consistency verified (no overrides of higher levels)
• LCA compliance confirmed (no violations of core principles)

Converted and distributed by TomeVault — claim your Tome and manage your conversions.