Onde gerenciar o acesso a um agregado? Seguindo as regras de design orientado a domínio

Seguindo os princípios do design orientado a domínio,

Digamos que estamos construindo um sistema de gestão de pedidos B2B. Um dos requisitos é que, para cada cliente/pedido/item de pedido, possamos designar pessoas para gerenciar o fluxo de pedidos.

Por exemplo, a BMW quer comprar rolamentos e fixadores e precisamos preparar uma oferta. Neste caso, a BWM é a cliente e o pedido contém dois itens: rolamentos e fixadores.

Mark foi designado para o cliente BMW, portanto, ele tem acesso a todo o pedido. Elon foi designado para o item de pedido de rolamentos, portanto, ele só pode gerenciar este item, por exemplo, ele pode calcular o preço da oferta.

O código poderia ser assim:

public class Order
{
    public CustomerId CustomerId { get; }
    private List<OrderItem> _items = [];
    ...
    public ChangeOrderHeader() // Only Mark can do that
    {
        ...
    }
}

public class OrderItem
{
    public OrderId OrderId { get; }
    ...
    public void PrepareOffer() // Available for Mark. Also for Elon if this is the bearing order item
    {
        ...
    }
}

A questão: como gerenciar a validação de permissão neste caso?

Meu primeiro pensamento foi tratar a validação de permissão como uma regra de negócios normal, então podemos ter algo assim:

public void PrepareOffer(User user)
{
    EnsurePermissions(user); // Validation is in method, it also could be a policy
    ...
}

O problema é que você precisa passar informações/políticas do usuário para todos os métodos dentro de um agregado. Além disso, no meu entendimento, o domínio deve se preocupar com o quê/como e não com quem .

Outra abordagem poderia ser validar a permissão no repositório, por exemplo, ao salvar o agregado, podemos verificar o que foi modificado e validar as permissões do chamador.

public class Repository(IUserAccessor userAccessor)
{
    public Task Save(Order order)
    {
        var user = userAccessor.GetCurrentUser();
        if(order.WasModified())
        {
            EnsureOrderPermissions(order, user);
        }
        ...
    }
}

Essa abordagem não produz sobrecarga de código, mas move a lógica de negócios para a camada de infraestrutura.

A próxima abordagem que me vem à mente é validar as permissões do usuário na camada de aplicação, antes de chamar métodos de domínio.

public OrderService(IUserAccessor userAccessor)
{
    public void PrepareOffer(Order order, OrderLineId orderLineId)
    {
        var user = userAccessor.GetCurrentUser();
        EnsureOrderLinePermissions(orderLineId, user);
        order.PrepareOrder(orderLineId);
    }   
}

Nesse caso, temos mais código do que na segunda abordagem, mas parece lógico verificar as permissões na camada de aplicação.

E a última abordagem poderia ser executar uma autorização específica de recurso no nível de autorização do endpoint, mas isso pode ser complicado de implementar.