using New.Application.Ports;
using New.Application.Worklist;
using New.Infrastructure.Legacy;
using New.Infrastructure.Persistence;

namespace New.Api.Resolution;

/// <summary>
/// The ONLY type in the whole solution that references both
/// <see cref="OwnedApplicationSource"/> and <see cref="LegacyCaseSource"/> -
/// Architecture.Tests rule 7 asserts exactly that. Every other type that
/// needs case data reaches it through a port (IApplicationSource for
/// by-id resolution, or IOwnedWorklistReader/ILegacyWorklistReader for the
/// merged worklist listing - deliberately different types, see those
/// interfaces' remarks) without ever knowing there are two sources at all.
/// This is the seam-hiding point of the whole "strangler fig" design: a
/// legacy aanvraagId keeps working transparently after adoption, because
/// this resolver - and only this resolver - knows to check the ownership
/// registry first and redirect to the owned copy when present.
/// </summary>
internal sealed class ApplicationSourceResolver(
    OwnedApplicationSource owned,
    LegacyCaseSource legacy,
    IOwnershipRegistry registry) : IApplicationSource
{
    public async Task<CaseDetail?> GetByLegacyIdAsync(int aanvraagId, CancellationToken ct)
    {
        var ownedId = await registry.LookupOwnedIdAsync(aanvraagId, ct);
        return ownedId is null
            ? await legacy.GetAsync(aanvraagId, ct)      // seam A
            : await owned.GetAsync(ownedId.Value, ct);    // owned
    }
}