Particionando recursos da API REST em áreas baseadas em domínios de negócios

Em uma API REST de aplicativo principal que abrange vários domínios relacionados, faz mais sentido dividir recursos em 'áreas' com base no domínio de negócios ao qual eles pertencem ou é melhor manter um único modelo?

Por exemplo, existem subdomínios 'Vendas' e 'Inventário'. Os usuários do sistema geralmente se preocupam apenas com um domínio por vez, mas são possíveis exceções. Existe um conceito de 'Item' existente nos dois domínios, para que possamos implementar o recurso 'item' de duas maneiras diferentes.

1. possui recursos diferentes para representar o conceito em cada domínio, cada recurso contendo apenas os dados relevantes:

   / sales / items /: id

   / inventário / itens /: id

2. possui um único recurso com todos os dados a serem usados ​​em todos os contextos:

   / items /: id

Também há muitos recursos que pertencem apenas a um dos domínios.

profissionais de 'áreas'

• é mais fácil entender a API para usuários que se preocupam apenas com um único domínio
• recursos mais fáceis de implementar (menos coisas para ler / atualizar de cada vez)
• os recursos podem ser mais especializados / otimizados para cada domínio específico
• capacidade de controlar o acesso aos recursos em um nível mais granular

profissionais de um único modelo unificado

• não há recursos duplicados para conceitos que pertencem a mais de um domínio
• se um usuário precisar trabalhar com vários domínios, ele precisará usar apenas uma única API que cubra todas as suas necessidades

O particionamento da API, conforme descrito acima, é uma maneira válida de reduzir a complexidade do contrato e da implementação da API? Eu não vi isso mencionado muito em lugar nenhum.

Há mais alguma coisa que precisa ser considerada para tomar uma decisão em favor de qualquer uma das abordagens?

Penso que este é o ajuste perfeito para o padrão de Contexto Limitado do Domain Driven Design.

Modelos grandes não escalam bem, é melhor dividi-los em modelos menores (contextos limitados) e declarar explicitamente seus relacionamentos (entidades comuns, interações entre contextos limitados etc.)

Nesse caso, você teria dois contextos limitados (vendas e estoque) com um recurso compartilhado (item). A interpretação do item no contexto de vendas pode ser um pouco diferente do que no contexto do inventário, e isso é ótimo.

Para usar esse padrão, você deve:

• identifique os limites de diferentes contextos (o que você fez parcialmente criando sub-raízes / vendas / e / estoque /)
• identificar recursos compartilhados (item) e descrever explicitamente qual é a interpretação do recurso em diferentes contextos limitados
• identificar interações entre contextos limitados (o que provavelmente está fora do escopo desta pergunta)

Nota sobre

profissionais de um único modelo unificado: sem recursos duplicados para conceitos que pertencem a mais de um domínio

Do ponto de vista REST, o recurso não é duplicado. Um recurso pode ser identificado por vários URIs, cada um pode ter representações diferentes (adequado para um determinado contexto limitado).

Eu acho que a regra geral deve ser a seguinte.

Se um item em si é impensável sem estar relacionado a vendas ou estoque, você deve optar pela opção 1.

Se um item puder existir sem nenhuma relação com vendas / estoque ou essa relação não for realmente forte em sua arquitetura, você poderá optar pela opção 2.