Este documento descreve a arquitetura dos services da camada de aplicação do Arah, especialmente após a refatoração do FeedService.
Cada service tem uma única responsabilidade bem definida:
Todos os services são registrados via Dependency Injection em ServiceCollectionExtensions:
Scoped (uma instância por requisição HTTP)Responsabilidade: Orquestrar operações de feed, delegando para services especializados.
Dependências (4):
IFeedRepository: Acesso aos dados de postsPostCreationService: Criação de postsPostInteractionService: Interações com postsPostFilterService: Filtragem e paginaçãoMétodos Principais:
ListForTerritoryAsync: Lista posts de um território (delega para PostFilterService)ListForTerritoryPagedAsync: Lista posts paginados (delega para PostFilterService)CreatePostAsync: Cria um novo post (delega para PostCreationService)LikeAsync: Adiciona like a um post (delega para PostInteractionService)CommentAsync: Adiciona comentário a um post (delega para PostInteractionService)ShareAsync: Compartilha um post (delega para PostInteractionService)Responsabilidade: Criar posts com todas as validações e lógica necessária.
Dependências (10):
IFeedRepository: Persistência de postsIMapRepository: Validação de entidades do mapaIAssetRepository: Validação de assetsIPostGeoAnchorRepository: Persistência de geo anchorsIPostAssetRepository: Persistência de associações post-assetISanctionRepository: Verificação de sançõesIFeatureFlagService: Verificação de feature flagsIAuditLogger: Logging de auditoriaIEventBus: Publicação de eventosIUnitOfWork: Gerenciamento de transaçõesMétodos Principais:
CreatePostAsync: Cria um post com validações completasValidações Realizadas:
Responsabilidade: Gerenciar interações com posts (likes, comentários, shares).
Dependências (5):
IFeedRepository: Acesso aos postsAccessEvaluator: Verificação de permissõesISanctionRepository: Verificação de sanções de interaçãoIAuditLogger: Logging de auditoriaIUnitOfWork: Gerenciamento de transaçõesMétodos Principais:
LikeAsync: Adiciona like a um postCommentAsync: Adiciona comentário a um postShareAsync: Compartilha um postValidações Realizadas:
Responsabilidade: Filtrar e paginar posts baseado em regras de visibilidade e acesso.
Dependências (3):
AccessEvaluator: Verificação de permissõesIUserBlockRepository: Verificação de bloqueiosIPostAssetRepository: Filtragem por assetMétodos Principais:
FilterPostsAsync: Filtra posts baseado em visibilidade, bloqueios e filtrosFilterAndPaginateAsync: Filtra e pagina postsFiltros Aplicados:
Para operações que podem falhar, o padrão Result<T> está disponível em Arah.Application/Common/Result.cs:
public sealed class Result<T>
{
public bool IsSuccess { get; }
public T? Value { get; }
public string? Error { get; }
}
Status: Estrutura criada, migração gradual em andamento.
Para operações de listagem com paginação:
public sealed class PagedResult<T>
{
public IReadOnlyList<T> Items { get; }
public int PageNumber { get; }
public int PageSize { get; }
public int TotalCount { get; }
public int TotalPages { get; }
public bool HasPreviousPage { get; }
public bool HasNextPage { get; }
}
Status: Implementado em FeedService.ListForTerritoryPagedAsync.
A configuração de Dependency Injection está centralizada em ServiceCollectionExtensions:
public static IServiceCollection AddApplicationServices(this IServiceCollection services)
{
// Core services
services.AddScoped<AccessEvaluator>();
services.AddScoped<CurrentUserAccessor>();
// Feed services (refactored)
services.AddScoped<PostCreationService>();
services.AddScoped<PostInteractionService>();
services.AddScoped<PostFilterService>();
services.AddScoped<FeedService>();
// Other services...
}
Para facilitar a criação de FeedService nos testes, foi criado FeedServiceTestHelper:
var dataStore = new InMemoryDataStore();
var service = FeedServiceTestHelper.CreateFeedService(dataStore, eventBus);
O helper cria automaticamente todas as dependências necessárias, incluindo os services especializados.
Os services ainda retornam tuplas (bool success, string? error, T? result). A migração para Result<T> está planejada para padronizar o tratamento de erros.
Services que acessam dados frequentemente consultados (ex: feature flags, territórios) podem se beneficiar de cache. Implementação futura planejada.
Além do feed, existem services de suporte a governança, filas e configurações calibráveis:
SystemConfig) com cache e auditoria.WorkItem (Work Queue genérica).DocumentEvidence e persistir conteúdo em storage via IFileStorage.WorkItemType.ModerationCase) e atualizar o estado do report/sanção.Responsabilidade: orquestrar operações de chat com governança territorial e performance:
PendingApproval e permitir aprovação por CuratorModeratorChatConversationStats para evitar agregações pesadas em hot pathsDependências (8):
IChatConversationRepository: persistência de conversas (canais/grupos/DM)IChatConversationParticipantRepository: participantes (grupos/DM) e estado de leitura/muteIChatMessageRepository: persistência e listagem cursor-based de mensagensIChatConversationStatsRepository: read model (última mensagem/preview/contagem)IUserRepository: checar UserIdentityVerificationStatusFeatureFlagCacheService: leitura cacheada de flags por territórioTerritoryFeatureFlagGuard: gates consistentes por território (ChatEnabled, canais, grupos, DM, mídia)AccessEvaluator: gates de membership/capability (Resident validado, Curator, Moderator, SystemAdmin)IUnitOfWork: commit transacionalRegras principais (MVP):
Performance:
(ConversationId, CreatedAtUtc, Id) com cursorO PostFilterService atualmente carrega todos os posts antes de filtrar. Para grandes volumes, a filtragem deve ser feita no nível do repositório.