ledger-live: Skill for Claude Code

Data Layer: Multiple Entities

Apply only when one API response maps to several autonomous entities. Use domain-data for the rules inside each entity and api package.

Source: Data Layer Advanced Use Case

Split Ownership

domain/entity/<first>/src/schema.ts
domain/entity/<second>/src/schema.ts
domain/api/<orchestrator>/src/api.ts

• Let each entity own its schema and inferred type. Add state, selectors, mocks, and tests only when that entity needs them.
• Let one domain/api package own the cross-entity response contract, request, transformation, and validation.
• Keep UI and feature state in features/flow.
• Keep app composition out of the domain package.

Process The Response

1. Fetch with RTK Query, createAsyncThunk, or both.
2. In the API layer, validate and transform each response collection with its owning entity schema.
3. Keep the result in RTK Query or dispatch the validated entities when slices must be hydrated.

Validate the collection before iterating over it: prefer entitySchema.array().parse(value) to .map() on untrusted data.

Test The Orchestration

• Use entity mock builders when available; otherwise build schema-valid fixtures.
• Test RTK Query endpoints, thunks, or their integration according to the chosen orchestration.
• When reducers are involved, create a minimal local store or use an existing domain test harness.
• Never import an app store or app alias into a domain test.
• Assert the validated result, cache entry, and any hydrated slice that the orchestration owns.
• Cover transport failure, invalid collection shape, and invalid entity data when relevant.