webiny-use-case-pattern

Define an interface with an execute method returning Result<T, E>, create an abstraction with createAbstraction, then implement the class and export it as default via createImplementation with its dependencies array matching the constructor parameter order.

Register your own class implementing the same UseCase interface using SomeUseCase.createImplementation with your custom logic. Your implementation replaces the default one in the DI container when registered through an Api.Extension src file.

A decorator implements the same interface as the use case it wraps, taking extra dependencies first and the decoratee last in the constructor. Register it with container.registerDecorator() inside a createFeature register function, not container.register().

Build failures occur when the Extension src prop omits the .ts file extension or when the file uses a named export instead of export default for the createImplementation call. Both are mandatory for files targeted directly by an Extension src.

Repositories resolve the CMS model first via GetModelUseCase, then call entry use cases like CreateEntryUseCase or UpdateEntryUseCase. CMS errors are wrapped in domain-specific errors, and repositories are registered in singleton scope.

Use Result.ok(value) for success, Result.fail(error) for failure, result.isFail() to check status, and result.value or result.error to access contents. Methods like isError(), getError(), and getValue() do not exist.