Partitionieren von REST-API-Ressourcen in Bereiche, die auf Geschäftsdomänen basieren

Ist es in einer REST-API für Hauptanwendungen, die mehrere verwandte Domänen abdeckt, sinnvoller, Ressourcen basierend auf der Geschäftsdomäne, zu der sie gehören, in "Bereiche" aufzuteilen, oder ist es besser, ein einzelnes Modell beizubehalten?

Beispielsweise gibt es die Unterdomänen "Vertrieb" und "Inventar". Benutzer des Systems kümmern sich normalerweise jeweils nur um eine Domäne, es sind jedoch Ausnahmen möglich. In beiden Domänen gibt es ein 'Item'-Konzept, sodass wir die' Item'-Ressource auf zwei verschiedene Arten implementieren können.

1. haben unterschiedliche Ressourcen, um das Konzept in jeder Domäne darzustellen, wobei jede Ressource nur die relevanten Daten enthält:

   / sales / items /: id

   / inventar / artikel /: id

2. eine einzige Ressource mit allen Daten haben, die in allen Kontexten verwendet werden sollen:

   / items /: id

Es gibt auch viele Ressourcen, die nur zu einer der Domänen gehören.

Profis von "Bereichen"

• Einfacheres Verständnis der API für Benutzer, die sich nur für eine einzelne Domain interessieren
• einfacher zu implementierende Ressourcen (weniger Dinge zum Lesen / Aktualisieren gleichzeitig)
• Ressourcen können für jede bestimmte Domäne spezialisierter / optimierter sein
• Möglichkeit, den Zugriff auf Ressourcen detaillierter zu steuern

Vorteile eines einzigen einheitlichen Modells

• Keine doppelten Ressourcen für Konzepte, die zu mehr als einer Domäne gehören
• Wenn ein Benutzer mit mehreren Domänen arbeiten muss, muss er nur eine einzige API verwenden, die alle seine Anforderungen abdeckt

Ist die oben beschriebene API-Partitionierung ein gültiger Weg, um die Komplexität sowohl des API-Vertrags als auch der Implementierung zu reduzieren? Ich habe nirgends viel erwähnt.

Gibt es noch weitere Dinge, die berücksichtigt werden müssen, um eine Entscheidung für einen der beiden Ansätze zu treffen?

Ich denke, dass dies die perfekte Passform für das Bounded Context- Muster von Domain Driven Design ist.

Große Modelle lassen sich nicht gut skalieren. Es ist besser, sie in kleinere Modelle (begrenzte Kontexte) aufzuteilen und ihre Beziehungen explizit zu deklarieren (gemeinsame Entitäten, Interaktionen zwischen begrenzten Kontexten usw.).

In diesem Fall hätten Sie zwei begrenzte Kontexte (Verkauf und Inventar) mit einer gemeinsam genutzten Ressource (Artikel). Die Interpretation des Artikels im Verkaufskontext kann etwas anders sein als im Inventarkontext, und das ist völlig in Ordnung.

Um dieses Muster zu verwenden, sollten Sie:

• Identifizieren Sie die Grenzen verschiedener Kontexte (was Sie teilweise durch Erstellen von Subroots / sales / und / inventar / getan haben).
• Identifizieren Sie gemeinsam genutzte Ressourcen (Element) und beschreiben Sie explizit die Interpretation der Ressource in verschiedenen begrenzten Kontexten
• Interaktionen zwischen begrenzten Kontexten identifizieren (was wahrscheinlich außerhalb des Rahmens dieser Frage liegt)

Hinweis zu

Vorteile eines einzigen einheitlichen Modells: Keine doppelten Ressourcen für Konzepte, die zu mehr als einer Domäne gehören

Aus REST-Sicht wird die Ressource nicht dupliziert. Eine Ressource kann durch mehrere URIs identifiziert werden, von denen jede unterschiedliche Darstellungen haben kann (passend für einen bestimmten begrenzten Kontext).

Ich denke, die Faustregel sollte die folgende sein.

Wenn ein Artikel selbst undenkbar ist, ohne mit Verkauf oder Inventar in Verbindung zu stehen, sollten Sie Option 1 wählen.

Wenn ein Artikel ohne Beziehung zu Verkauf / Inventar existieren kann oder diese Beziehung in Ihrer Architektur nicht wirklich stark ist, können Sie Option 2 wählen.