Architecting for Scale, 2. Auflage

Kapitel 6. Dienstleistungseigentümerschaft-STOSA

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In Kapitel 3 haben wir besprochen, was ein Service ist und wie er genutzt werden kann, um die Komplexität einer Anwendung auf viele verschiedene Entwicklungsteams aufzuteilen, von denen jedes an seiner eigenen Codebasis arbeitet und seine eigenen Services unterstützt. Wir haben besprochen, wie man die Größe von Diensten bestimmt und wie sie zusammenarbeiten sollten.

Wir sind aber nicht näher darauf eingegangen, was es für ein Team bedeutet, einen Service zu "besitzen" und warum dieser Besitz wichtig ist. In diesem Kapitel werden wir erklären, was mit Service Ownership gemeint ist und was notwendig ist, damit eine Single Team Owned Service Architecture funktioniert.

Service-Architektur im Besitz eines Teams

Was ist eine Single Team Owned Service Architecture (STOSA)? STOSA ist ein wichtiges Leitprinzip für große Organisationen, die viele Entwicklungsteams haben, die Dienste besitzen und verwalten, die eine oder mehrere Anwendungen umfassen.

Was bedeutet es, einen STOSA-Antrag und eine STOSA-Organisation zu haben? Um STOSA zu sein, musst du die folgenden Kriterien erfüllen:

• Du musst eine Anwendung haben, die mit einer servicebasierten Architektur aufgebaut ist .

• Es muss mehrere Entwicklungsteams geben, die für die Erstellung und Pflege der Anwendung verantwortlich sind.

• Jeder einzelne Dienst ...