tercul-backend/internal/app/work

Work Service

This package manages the core Work domain entity in the Tercul platform. It provides the primary application service for all operations related to literary works, including creating, updating, deleting, and retrieving them.

Architecture Overview

The work service is designed following the Command Query Responsibility Segregation (CQRS) pattern. This separation makes the service more maintainable, scalable, and easier to understand.

Key Components

• service.go: The main entry point for the work service. It composes the WorkCommands and WorkQueries into a single Service struct, which is then used by the rest of the application (e.g., in the GraphQL resolvers).

• commands.go: Contains all the command handlers for mutating Work entities. This includes:

  • CreateWork: Creates a new work.
  • UpdateWork: Updates an existing work.
  • DeleteWork: Deletes a work.
  • AnalyzeWork: Triggers a comprehensive linguistic analysis of a work and its translations.
  • MergeWork: Merges two works into one, consolidating their translations and statistics.

• queries.go: Contains all the query handlers for retrieving Work data. These handlers return specialized WorkDTO read models to ensure a clean separation between the domain and the API layer.

• dto.go: Defines the WorkDTO struct, which is the read model used for all query responses.

• interfaces.go (external): The service depends on the WorkRepository interface defined in internal/domain/interfaces.go for data persistence.

Usage

The work.Service is intended to be injected into the application's top-level layers, such as the GraphQL resolvers, which then call the appropriate command or query handlers.

Example: Creating a Work

// In a GraphQL resolver
work, err := workService.Commands.CreateWork(ctx, &domain.Work{...})

Example: Retrieving a Work

// In a GraphQL resolver
workDTO, err := workService.Queries.GetWorkByID(ctx, workID)

Dependencies

• internal/domain: Uses and returns the core Work domain entity and the WorkDTO read model.
• internal/app/authz: Relies on the authorization service to perform permission checks before executing commands like UpdateWork and DeleteWork.
• internal/app/analytics: The AnalyzeWork command calls the analytics service to perform and store linguistic analysis.
• internal/domain/search: Uses the SearchClient interface to index works in the search engine after they are created or updated.
• Database: Persists all Work data via the WorkRepository.
• Logging: Uses the centralized logger from internal/platform/log.
• OpenTelemetry: All command and query methods are instrumented for distributed tracing.