Problema: Controllers nao validam adequadamente entradas antes de chamar services.

Exemplo:

• FeedController.CreatePost aceita geoAnchors sem validar limites antes de passar para o service

Impacto: Erros de validacao chegam muito tarde no pipeline, dificultando tratamento adequado.

Recomendacao:

• Adicionar FluentValidation ou Data Annotations nos DTOs
• Implementar ModelState validation nos controllers
• Criar validators customizados para regras complexas (ex: geolocalizacao)

Problema: Services retornam tuplas (bool success, string? error, T? result) mas nao ha padronizacao.

Exemplo:

// FeedService retorna tupla
public async Task<(bool success, string? error, CommunityPost? post)> CreatePostAsync(...)

// TerritoryService retorna tupla diferente
public async Task<(bool success, string? error, Territory? territory)> GetByIdAsync(...)

Impacto: Dificulta tratamento uniforme de erros e padronizacao de respostas da API.

Recomendacao:

• Criar Result<T> ou OperationResult<T> padronizado
• Ou usar exceptions tipadas (ex: DomainException, ValidationException)
• Documentar estrategia de tratamento de erros

Problema: Metodos de listagem nao implementam paginacao.

Exemplo:

• FeedService.ListForTerritoryAsync retorna IReadOnlyList<CommunityPost> sem limites
• TerritoryService.ListAvailableAsync retorna todas as territories
• MapService.ListEntitiesAsync sem paginacao

Impacto: Pode causar problemas de performance e memoria com grandes volumes de dados.

Recomendacao:

• Implementar PagedResult<T> com PageNumber, PageSize, TotalCount
• Adicionar parametros de paginacao nos metodos de listagem
• Implementar limites padrao (ex: max 100 itens por pagina)

Problema Original: Nao ha estrategia de cache para dados frequentemente acessados.

Solucao Implementada:

• ✅ Cache em memoria (IMemoryCache) implementado na Fase 2
• ✅ Cache distribuido (Redis) implementado na Fase 3
• ✅ IDistributedCacheService com fallback automatico para IMemoryCache
• ✅ Todos os cache services migrados para Redis (7 services)
• ✅ Cache de territories, feature flags, membership status implementado

Status: 100% implementado (Fase 2 + Fase 3)

Problema: Logging nao e consistente e faltam informacoes contextuais.

Exemplo:

• RequestLoggingMiddleware loga mas nao inclui correlation ID
• Services nao logam operacoes importantes
• Falta logging de operacoes de negocio (ex: criacao de post, report)

Impacto: Dificulta debugging e observabilidade em producao.

Recomendacao:

• Adicionar correlation ID (via middleware)
• Usar structured logging (Serilog) com contexto
• Logar operacoes criticas com nivel apropriado
• Adicionar metricas (ex: contadores de operacoes)

Problema Original: Nao ha tratamento de concorrencia otimista.

Solucao Implementada:

• ✅ RowVersion adicionado em 4 entidades criticas:
  • CommunityPostRecord, TerritoryEventRecord, MapEntityRecord, TerritoryMembershipRecord
• ✅ Configuracao no ArapongaDbContext usando IsRowVersion()
• ✅ Tratamento de DbUpdateConcurrencyException no CommitAsync
• ✅ ConcurrencyHelper criado para retry logic
• ✅ Repositories atualizados para rastrear entidades corretamente
• ✅ Testes de concorrencia implementados

Status: 100% implementado na Fase 3

---

Problema: Mistura de Singleton e Scoped sem justificativa clara.

Exemplo:

// InMemory: Singleton
builder.Services.AddSingleton<ITerritoryRepository, InMemoryTerritoryRepository>();

// Postgres: Scoped
builder.Services.AddScoped<ITerritoryRepository, PostgresTerritoryRepository>();

Problema: InMemoryUnitOfWork e Singleton mas nao gerencia estado compartilhado corretamente.

Impacto: Possiveis problemas de thread-safety e estado compartilhado incorreto.

Recomendacao:

• Documentar razao para diferentes lifetimes
• Considerar usar Scoped mesmo para InMemory (mais seguro)
• Ou garantir thread-safety em Singletons

Problema: InMemoryUnitOfWork nao faz nada, apenas retorna Task.CompletedTask.

Exemplo:

public sealed class InMemoryUnitOfWork : IUnitOfWork
{
    public Task CommitAsync(CancellationToken cancellationToken)
    {
        return Task.CompletedTask; // Nao faz nada!
    }
}

Impacto:

• Dificulta testes de transacoes
• Nao ha rollback em caso de erro
• Comportamento diferente entre InMemory e Postgres

Recomendacao:

• Implementar rollback em InMemory (desfazer mudancas em caso de erro)
• Ou documentar que InMemory nao suporta transacoes
• Considerar usar transacoes mesmo em memoria (para testes)

Problema Original: InMemoryEventBus executa handlers sincronamente.

Solucao Implementada:

• ✅ BackgroundEventProcessor criado como BackgroundService
• ✅ Fila de eventos em memoria (ConcurrentQueue)
• ✅ Processamento concorrente (ate 5 eventos simultaneos)
• ✅ Retry logic com backoff exponencial (ate 3 tentativas)
• ✅ Dead letter queue para eventos que falharam apos todas as tentativas
• ✅ Resolucao dinamica de handlers via IServiceProvider

Status: 100% implementado na Fase 3

Problema: Alguns metodos retornam null, outros retornam tuplas com erro.

Exemplo:

// Retorna null
public Task<CommunityPost?> GetPostAsync(Guid postId, ...)

// Retorna tupla
public async Task<(bool success, string? error, CommunityPost? post)> CreatePostAsync(...)

Impacto: Dificulta tratamento uniforme de erros.

Recomendacao: Padronizar estrategia (Result ou exceptions).

Problema: Services nao validam se dependencias estao configuradas corretamente.

Exemplo: FeedService recebe 12 dependencias mas nao valida se sao null.

Impacto: Erros em runtime ao inves de compile-time.

Recomendacao:

• Usar null-checking no construtor
• Ou usar required properties (C# 11+)
• Validar configuracao na inicializacao

---

Problema Original: FeedService tinha 12 dependencias, violando Single Responsibility Principle.

Solucao Implementada:

• ✅ Extraido PostCreationService (criacao de posts)
• ✅ Extraido PostInteractionService (likes, comments, shares)
• ✅ Extraido PostFilterService (filtros e visibilidade)
• ✅ FeedService agora atua como orquestrador/facade com apenas 4 dependencias

Dependencias Antigas (12):

• IFeedRepository, AccessEvaluator, IFeatureFlagService, IAuditLogger, IUserBlockRepository, IMapRepository, IPostGeoAnchorRepository, IPostAssetRepository, IAssetRepository, ISanctionRepository, IEventBus, IUnitOfWork

Dependencias Atuais (4):

• IFeedRepository, PostCreationService, PostInteractionService, PostFilterService

Beneficios:

• ✅ Melhor separacao de responsabilidades (SRP)
• ✅ Codigo mais testavel e manutenivel
• ✅ Reducao de complexidade ciclomatica
• ✅ Facilita evolucao independente de cada funcionalidade

Problema: Validacoes repetidas em varios services.

Exemplo:

// Em varios services
if (territoryId == Guid.Empty)
{
    return (false, "Territory ID is required.", null);
}

Recomendacao:

• Criar ValidationHelper ou extension methods
• Usar FluentValidation
• Criar value objects para IDs (ex: TerritoryId, UserId)

Problema: Duplicacao massiva de registros de repositories.

Exemplo: 30+ linhas repetidas para InMemory vs Postgres.

Recomendacao:

• Criar metodo de extensao AddRepositories<TImplementation>()
• Usar reflection para registrar automaticamente
• Ou usar convention-based registration

Problema: Valores hardcoded espalhados pelo codigo.

Exemplo:

const int MaxAnchors = 50;
const int Precision = 5;
private const int ReportThreshold = 3;

Recomendacao:

• Mover para configuracao (appsettings.json)
• Criar AppSettings ou FeatureSettings class
• Usar Options pattern do ASP.NET Core

---

Problema: Potenciais queries N+1 em varios lugares.

Exemplo:

// FeedService.ListForTerritoryAsync
var posts = await _feedRepository.ListByTerritoryAsync(...);
// Depois filtra em memoria, mas pode precisar buscar dados relacionados

Recomendacao:

• Usar Include() no EF Core para eager loading
• Implementar projection queries (Select apenas campos necessarios)
• Considerar DTOs especificos para queries

Problema: Services carregam entidades completas quando precisam apenas de alguns campos.

Exemplo:

• FeedService.CreatePostAsync carrega CommunityPost completo mas so precisa de alguns campos para validacao
• ReportService carrega post completo para verificar territorio

Recomendacao:

• Criar metodos de repository que retornam apenas dados necessarios
• Usar projections (Select)
• Implementar DTOs leves para operacoes de leitura

Problema: Nao ha documentacao de indices estrategicos.

Recomendacao:

• Documentar indices criados nas migrations
• Adicionar indices para:
  • TerritoryMembership (UserId + TerritoryId)
  • CommunityPost (TerritoryId + Status + CreatedAt)
  • ModerationReport (TargetType + TargetId + CreatedAt)
• Revisar queries lentas e adicionar indices

Problema Original: Event handlers executam sincronamente, bloqueando request.

Solucao Implementada:

• ✅ BackgroundEventProcessor processa eventos em background
• ✅ Outbox pattern ja implementado para eventos criticos
• ✅ Retry logic e dead letter queue implementados
• ✅ Processamento nao bloqueia requests

Status: 100% implementado na Fase 3

Status Anterior:

• FeedService tinha muitas responsabilidades (criacao, listagem, interacoes)
• Program.cs fazia configuracao, DI, middleware setup

Melhorias Implementadas:

• ✅ FeedService refatorado: agora tem apenas 4 dependencias e atua como orquestrador
• ✅ PostCreationService: responsavel apenas por criacao de posts
• ✅ PostInteractionService: responsavel apenas por likes, comentarios e shares
• ✅ PostFilterService: responsavel apenas por filtragem e paginacao
• ✅ Program.cs simplificado: configuracao extraida para ServiceCollectionExtensions

Status Atual:

• FeedService: ~115 linhas, 4 dependencias (reducao de 70%)
• PostCreationService: ~150 linhas, 10 dependencias (focado em criacao)
• PostInteractionService: ~120 linhas, 5 dependencias (focado em interacoes)
• PostFilterService: ~90 linhas, 3 dependencias (focado em filtragem)

Pendente:

• ReportService: Ainda gerencia reports E aplica sancoes automaticas (pode ser refatorado no futuro)

Problemas:

• Algumas interfaces sao muito grandes
• IFeedRepository tem muitos metodos

Exemplo:

public interface IFeedRepository
{
    Task<IReadOnlyList<CommunityPost>> ListByTerritoryAsync(...);
    Task<IReadOnlyList<CommunityPost>> ListByAuthorAsync(...);
    Task<CommunityPost?> GetPostAsync(...);
    Task AddPostAsync(...);
    Task UpdateStatusAsync(...);
    Task AddLikeAsync(...);
    Task AddCommentAsync(...);
    Task AddShareAsync(...);
    Task<int> GetLikeCountAsync(...);
    Task<int> GetShareCountAsync(...);
}

Recomendacao:

• Separar em IPostRepository e IPostInteractionRepository
• Ou manter se fizer sentido no dominio

1. ✅ Implementar paginacao - Criado PagedResult<T> e PaginationParameters, implementado em FeedService.ListForTerritoryPagedAsync
2. ✅ Padronizar tratamento de erros - Criado Result<T> e OperationResult (base para migracao futura)
3. ✅ Adicionar validacao de entrada - Implementado FluentValidation com CreatePostRequestValidator e TerritorySelectionRequestValidator (corrigido para usar Enum.TryParse)
4. ✅ Refatorar FeedService - Quebrado em PostCreationService, PostInteractionService e PostFilterService (ADR-009)
5. Implementar cache - Pendente (futuro)
6. ✅ Corrigir InMemoryUnitOfWork - Documentado comportamento e compatibilidade de interface
7. ✅ Isolamento de Testes - Melhorado ApiFactory para criar InMemoryDataStore isolado por instancia

8. ✅ Extrair configuracao de DI - Extraido para ServiceCollectionExtensions (melhor organizacao)
9. ✅ Adicionar logging estruturado - Implementado CorrelationIdMiddleware e RequestLoggingMiddleware com correlation ID
10. ✅ Implementar rate limiting - Implementado na Fase 1
11. ⚠️ Otimizar queries - Parcial (N+1 resolvido na Fase 2, analise continua necessaria)
12. ⚠️ Adicionar indices - Parcial (indices basicos criados, analise continua necessaria)
13. ✅ Processar eventos assincronamente - Implementado na Fase 3 (BackgroundEventProcessor)