effect-context-witness

Use Context.Service witnesses to remove non-persisted fields like correlation or transaction IDs from Effect schemas, keeping persisted data clean. This decouples runtime dependency injection from your domain model by providing non-essential fields via separate context services.

Use the witness pattern for existence or value injection like request context, and the capability pattern for operational behavior like validation, clock, or logging. This distinction ensures you model dependencies correctly by separating data existence from functional operations.

Model reusable operations like generation, validation, or database access as Context services using the capability pattern. This allows business logic to depend on explicit functions rather than globals, requiring type-level service specifications for proper injection.

Yes, Context.Service witnesses provide straightforward testing strategies for Effect schemas. By decoupling ephemeral runtime data and operational capabilities, you can inject mock dependencies during testing to isolate and verify schema behavior.

Hard-coupling ephemeral runtime data like transaction markers to Effect schemas pollutes persisted data. Removing these non-essential fields and providing them via Context witnesses keeps domain models minimal and persistence-friendly.

Yes, modeling behavior as capabilities requires explicit type-level service requirements in Effect. This ensures business logic declares its operational dependencies like clock or logging methods at the type level for safe dependency injection.