aidd-structure

name	aidd-structure
description	Enforces source code structuring and interdependency best practices. Use when creating folders, moving files, adding imports, or when the user asks about architecture, layering, or module dependencies.

Standard folder structure

types ← services ← plugins ← components
  ↑         ↑         ↑
  └─────────┴─────────┘ (types only depend on types)

Dependency rules

LayerDependency {
  layer: "components" | "plugins" | "services" | "types"
  mayDependOn: String[]
  mustNotDependOn: String[]
}

DependencyRules [
  { layer: "components", mayDependOn: ["plugins (Observe<Data>, void actions)", "types"], mustNotDependOn: ["services"] },
  { layer: "plugins", mayDependOn: ["services", "types", "other plugins"], mustNotDependOn: [] },
  { layer: "services", mayDependOn: ["other services", "types"], mustNotDependOn: ["components", "plugins"] },
  { layer: "types", mayDependOn: ["other types"], mustNotDependOn: ["everything else"] }
]

Constraints {
  Never: components → services
  Never: services → components or plugins
  Never: types → anything except types
}

---

components

UI components or elements (also called "elements").

From plugins: only Observe for reactive re-renders and void-returning action functions.

plugins (if using @adobe/data/ecs for state)

ECS Database.Plugin declarations. Usually depend on services, types, and other plugins.

services

Asynchronous data services, each in its own folder. Immutable data only. Adhere to namespace guidelines.

Async patterns only: Observe, Promise, AsyncGenerator, void actions.

External code depends only on interfaces, never on implementations.

types

Pure functional types and associated pure functions. Adhere to namespace guidelines.

Nested structure