Richtlinie: Schichten
Diese Richtlinie beschreibt Strategien für die Aufteilung eines Systems in mehrere Schichten.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Richtlinien für Schichtung

Schichtung ist eine logische Partitionierung von Subsystemen in eine Reihe von Gruppen mit bestimmten Regeln, die festlegen, wie die Beziehungen zwischen Schichten geformt werden können. Die Schichtung ist eine Möglichkeit, Abhängigkeiten zwischen Subsystemen einzuschränken, war zur Folge hat, dass das System loser gekoppelt und damit einfacher zu verwalten ist.

Die Kriterien für die Gruppierung von Subsystemen folgen bestimmten Mustern:

  • Sichtbarkeit. Subsysteme können nur von Subsystemen abhängig sein, die sich in derselben Schicht oder der direkt untergeordneten Schicht befinden.
  • Unbeständigkeit.
    • Stellen Sie in die höchsten Schichten solche Elemente, die sich ändern, wenn sich Benutzeranforderungen ändern.
    • Stellen Sie in die untersten Schichten solche Elemente, die sich ändern, wenn sich die Implementierungsplattform (Hardware, Programmiersprache, Betriebssystem, Datenbank usw.) ändert.
    • Stellen Sie in die mittleren Schichten solche Elemente, die generell auf weite Bereiche von Systemen und Implementierungsumgebungen anwendbar sind.
    • Fügen Sie Schichten hinzu, wenn zusätzliche Partitionen innerhalb dieser weit gefassten Kategorien Ihnen helfen, das Modell zu organisieren.
  • Allgemeingültigkeit. Abstrakte Modellelemente werden eher in die unteren Schichten des Modells gestellt. Wenn die Elemente nicht implementierungsspezifisch sind, neigen sie eher zu den mittleren Schichten.
  • Anzahl der Schichten. Für kleine Systeme reichen drei Schichten aus. Für komplexe Systeme sind im Allgemeinen 5-7 Schichten ausreichend. Mehr als 10 Schichten sollten in jedem Fall mit Argwohn begutachtet werden, da mit steigender Anzahl von Schichten auch die Komplexität zunimmt. Im Folgenden finden Sie einige Faustregeln, an die Sie sich halten sollten:

# Klassen

# Schichten

0-10

Keine Schichtung erforderlich

10-50

2 Schichten

25-150

3 Schichten

100-1000

4 Schichten

Subsysteme und Pakete in einer bestimmten Schichten dürfen nur von Subsystemen abhängig sein, die sich in derselben oder der direkt untergeordneten Schicht befinden. Eine Nichteinhaltung dieser Abhängigkeitseinschränkung beeinträchtigt die Architektur und macht das System fehleranfällig und schwierig zu verwalten.

Ausnahmen bilden Subsysteme, die direkten Zugriff auf Services der unteren Schichten benötigen. Es muss eine bewusste Entscheidung darüber getroffen werden, wie primitive Services im System gehandhabt werden, wie z. B. Drucken, Nachrichten senden usw. Es macht wenig Sinn, Nachrichten auf untere Schichten zu beschränken, wenn das Problem durch Implementierung von Aufruf-Passthroughs in den mittleren Schichten effektiv gelöst werden kann.

Partitionierungsmuster

Durch eine zusätzliche Partitionierung in den oberen Schichten des Systems kann das System besser organisiert werden. Die folgenden Richtlinien für Partitionierung beschreiben verschiedene Aspekte, die beachtet werden müssen:

  • Benutzerorganisation. Subsysteme können entlang von Linien organisiert werden, die die Verteilung der Funktionalität in der Geschäftsorganisation widerspiegelt (z. B. Partitionierung nach Abteilungen). Diese Partitionierung findet häufig in einem frühen Stadium des Designs statt, weil ein vorhandenes Unternehmensmodell eine streng organisationsorientierte Partitionsstruktur hat. Dieses Organisationsmuster betrifft häufig nur die oberen Schichten anwendungsspezifischer Services und "verschwindet" häufig während der Weiterentwicklung des Designs.
    • Eine Partitionierung entlang den Benutzerorganisationslinien kann ein guter Ausgangspunkt für das Modell sein.
    • Die Struktur der Benutzerorganisation ist über einen längeren Zeitraum hinweg nicht stabil (aufgrund einer Umorganisation des Unternehmens) und damit keine taugliche Langzeitbasis für die Systempartitionierung. Die interne Organisation des Systems muss eine Weiterentwicklung des Systems und eine von der Organisation des unterstützten Unternehmens unabhängige Wartung zulassen.
  • Kompetenz- und Know-how-Bereiche. Subsysteme können so organisiert werden, dass die Zuständigkeiten für Teile des Modells auf verschiedene Gruppen innerhalb der Entwicklungsorganisation verteilt werden. Gewöhnlich findet dies in den mittleren und unteren Schichten des Systems statt und spiegelt den Bedarf an speziellem Know-how während der Entwicklung und Unterstützung komplexer infrastruktureller Technologie wider. Beispiele für solche Technologien sind Netz- und Verteilungsmanagement, Datenbankmanagement, Kommunikationsmanagement und Prozesssteuerung. Die Partitionierung entlang von Kompetenzlinien kann auch in den oberen Schichten stattfinden, wenn spezielle Kompetenzen in der Problemdomäne erforderlich sind, um die Schlüsselfunktionalität des Geschäfts verstehen und unterstützen zu können. Beispiele hierfür sind Anrufmanagement (Telekommunikation), Wertpapierhandel, Bearbeitung von Versicherungsansprüchen, Steuerung des Luftverkehrs, um nur einige wenige zu nennen.
  • Systemverteilung. Jede der Schichten des Systems können zusätzlich "horizontal" partitioniert werden, um die physische Verteilung der Funktionalität darzustellen.
    • Eine Partitionierung zur Darstellung der Verteilung kann helfen, die Netzkommunikation während der Ausführung des Systems zu visualisieren.
    • Eine solche Partitionierung kann sich jedoch auch bewirken, dass sich das System schwieriger ändern lässt, wenn sich das Deployment-Modell signifikant ändert.
  • Vertrauliche Bereiche. Einige Anwendungen, insbesondere solche, für die die spezielle Sicherheitsberechtigungen entwickelt und/oder unterstützt werden müssen, erfordern eine zusätzliche Partitionierung entlang von Zugriffsberechtigungslinien für geschützten Zugriff. Software, die den Zugriff auf vertrauliche Bereiche steuert, muss von Personal mit den entsprechenden Berechtigungen entwickelt und verwaltet werden. Wenn die Anzahl der Personen mit einem solchen Hintergrund im Projekt beschränkt ist, muss die Funktionalität, die besondere Berechtigungen erfordert, in Subsysteme unterteilt werden, die unabhängig von anderen Subsystemen mit Schnittstellen zu den vertraulichen Bereichen entwickelt werden. Die Schnittstellen sind der einzige sichtbare Aspekt dieser Subsysteme.
  • Variabilitätsbereiche. Funktionalität, die eher optional ist und somit nur in einigen Varianten des Systems bereitgestellt wird, muss auf unabhängige Subsysteme verteilt werden, die unabhängig von der verbindlichen Funktionalität des Systems entwickelt und bereitgestellt werden.